I'm a Comcast cable modem subscriber. As far as I know, I'm not on their black list yet. However, I find the very notion of a black list fundamentally unacceptable.
I'm paying for a service which is supposed to give me a certain quantity of upstream and downstream bandwidth (384/3.5 in my case). As far as I'm concerned, I should be able to use every last kilobit of that allocation, 24 hours a day, 7 days a week, if I want. I don't, and I don't ever plan to, but I should have the option.
The problem that the article glosses over is that the consumer-grade ISP's are massively oversubscribed. Yeah, your transfer rates are theoretically what they say they are, but you're sharing that pipe with 5000 of your neighbors. And the ISP's often don't have enough bandwidth at their headends to support the triburary peak busy hour traffic. They need to fix this or stop making such hyperbolic claims about the speed and capacity of the service they offer. And if they are going to limit your total bandwidth consumption, then they need to tell you how much you get and allow you to monitor how much you have left (and even allow you to buy more).
To be fair, Comcast has reasonable prices (I pay about $43/month for my service) and once I got everything working, I've had excellent service for going on two years. From an availability/uptime standpoint, they do great. The value is quite good. Being secretive about their bandwidth consumption policies is not good.
This all highlights the point that an increasing number of users require very large amounts of bandwidth in their homes (for whatever reasons). The ISP's need to realize this and impliment solutions that enable this level of service.
The origional IBM PC keyboards, those heavy, rather clunky clickety-click input devices from the 80's and early 90's are, IMHO, the best computer keyboards ever made.
They were designed to have a touch and feel very similar to the IBM Selectric (sp?) typewriters. [Typewriters are an ancient device which uses an ink ribbon and an impact device to print letters on paper.] Well-seasoned executive assistants will tell you that the Selectric's were the best electronic typewriters ever made -- this is due largely to the touch and feel of the keyboard.
The old IBM keyboards were also quite sturdy... I'd say they weighed in at around 5 lbs (2.4 kg) or so. They make handy weapons, too, for pummeling over-zealous managers into submission:)
You can still find these keyboards at flea markets, computer shows, and on eBay. They'll be used, and you may have to get an adapter from the large DIN plug to PS2. Most of them didn't have the goofy Windows keys either, but who cares?
That failing, your next best bet is to go to your local computer superstore and try out all their keyboards. I personally avoid ones that do not have the standard configuration for the arrow keys and insert/delete.../page down, since that messes with my muscle memory.
I'm fortunate enough to have a job where I can pretty much come and go as I please, so long as my work gets done. I realize that this is not the case in many companies, but my current company, and my last two companies (Cisco and IBM) have all been pretty good about this.
I think that nit-picking about when developers get into work is just plain pointless. Obviously, if you have to be at various meetings or if you have a customer-facing role, your schedule will be more restricted. But barring those circumstances, what difference does it make if you work 9-5, 10-6, 11-7, or 12-8? As long as you get your work done and your schedule doesn't interfere with the normal flow of business and work at your company, who the hell cares?
My work schedule is largely dictated by my sleep schedule, which is dictated by my body. I function best by sleeping from about 1am to 9:30 or 10am. (11am is better still!). Trying to move that around just makes me less productive, more grumpy, and unhealthy in general. I have friends who have vastly different sleep schedules from me... some like to get up at the butt-crack of dawn, and some sleep mostly during daylight hours. Clearly, you can take this too far... there are job functions that require you to actually be in the office at the same time as your co-workers. But that still allows for a great deal of flexibility.
And remember, flex means flex. If your normal work week is 40 hours, and you end up staying at work late one night fixing a bug, then you should be able to get in late or leave early another day in the near future. Aa long as the system is not abused, it works great and makes for happy workers and optimal productiviy.
The exception to all this is that I have a standing agreement with my supervisors that if they need me in early or need my to stay late, I'll happily comply. They don't ask this of me very often, but when they do, I drink an extra cup or two of coffee and deal with it. So they know I'm always available in emergency situations (even on weekends, as necessary) and I know that if I want to take off early on a Friday or sleep in after a party, I'm good to go.
Again, my style may not be your style, but the general principles, I think, make for a very satisfying work environment.
I'm not sure that "insecure by design" is quite fair to the hard-working folks who developed this near-ubiquitous MTA.
A fairer assessment is that, when sendmail was designed, security was not as big an issue as it has become today. And in their defense, they do seem quite good about notifying people when vunerabilities arise and releasing fixes as quickly as possible.
That being said, sendmail is a pain in the ass. You have to remember that when sendmail was developed, there were many different mail protocols (besides SMTP), and sendmail had to support all of them -- this is why sendmail config files are so darned complex and unreadable. The vast majority of those have faded into obscurity, so subsequent products, like Postfix, can be much simpler and less complex and, thus, more likely to be secure. For a long time, sendmail was the only choice for a real MTA, but I think Postfix has proven itself a worthy successor.
Redhat has their up2date service... however, you have to pay for it. It definitely notifies you about updates for each of your systems. Supposedly, you can schedule maintenence via their website for all of your machines. I used it for a while on a trial basis, and it seemed to work OK.
However, I object to having to pay for free software:)
Anyone want to get together and work on an open-source auto-update package?
The CCNA certification covers a rather broad, albeit not very deep (IMHO) range of networking concepts and technologies, protocols, etc., as I'm sure you've read in the course descriptions. I don't have any of the CC* certifications myself, but I have been working in networking since about 1998, and I worked at Cisco for about 3.5 years.
I think you should go ahead and take the course. Let me give you a couple reasons why.
1. If you're not knowledgable about networking, you should be. Networking and the Internet in general, as we all now, are increasingly critical technologies for software engineers in almost all businesses. You should have at least a high-level understanding about how and why they work; the more you know, the better you will be.
2. At Cisco, CCNA's weren't really considered very useful... you were expected to know or learn whetever you needed to know for your job, certification or not. However, many companies encourage or require that their network administrators and other IT folks get CCNA's, which indicates to me that they place some value in the skill-set implied by having such a certification. Personally, if I'm the hiring manager and I care about your networking knowledge, I'm going to quiz you on networking anyway, and not trust that the CCNA means anything in particular.
Having a CCNA can't possibly hurt you. Even if your work isn't related to networking, it shows that you have a diversity of skills and interests, and that you have sensitivity to issues outside of your core skill set. It also means that I might be able to use you on networking-related projects, which increases your value to me as an employee.
3. Hell, you may find, as I did, that networking is really fun stuff and that you'd like to persue it further. No loss there either!
Let me close by saying that passing the CCNA test only means that you knew a certain set of material on a particular day. It doesn't make you a networking expert. If you don't use those skills, you'll lose them, just like anything else. Keep reading about new technologies, and, if you can, fiddle with networks from time to time. Keep up your intuition and troubleshooting skills. Knowing how to debug network problems comes in handy at the strangest times:)
I used to work at a major network hardware company. They had outsorced a large chunk of QA work to some contractors in India -- some script-writing, some regression tests, and other sundry tasks. Without necessarily making any broad generalizations about Indian contractors or foreign contracting in general, let me share my experiences and impressions with you, in the hopes that you won't make the same mistake that my company made.
1. Time zone: I was on the East Coast (EST/EDT). I beleive that India was about 12 hours away from us, give or take. This meant that basically anything you asked them to do took at least 1 full working day, since by the time I got into work, they were in bed. You can just imagine the problems this caused when deadlines or other time-critical matters were involved.
2. Language: Again, without making any broad generalizations... Their English sucked. It was nearly impossible to communicate with them on the phone and their written English was less than acceptible. Also, based on serveral very frustrating experiences with the whole group, I concluded that their comprehention of written English was equally poor. We finally found a guy there who could understand English well enough to explain things to the rest of the group, but even then, my confidence level was quite low.
3. Work Ethic/Product: Both the group in question and several other Indians I've worked with since then have had some similar issues w/r/t how they worked and what they produced. Again, not to generalize... If you give them very clear, step-by-step instructions to perform a discrete task, they generally will perform the task quite thoroughly. However, if the procedure requires any deviation from the norm or any creativity or synthesis, you're better off doing it yourself, because they'll never figure it out.
We also had problems getting them to listen to anyone other than management -- they basically ignored team lead's, including myself.
In their defense, I understand that the education system in India teaches them to work this way; it has a large focus on rote memorization and obeyance of authority. That's great, and it seems to work for them. However, that's not how we work in the US, and folks who have gone to US (or European or Chinese) schools and worked with others of the similar ilk will get very frustrated trying to mesh with thinking processes that are polar opposites of their own. Furthermore, I find this thinking process thoroughly unproductive and pretty much useless in an Engineer.
Now, I'm just waiting for someone to write back flaming me for being some kind of racist, so let me state once more that I am relating my personal experiences with certain Indians. I went to grad school with several amazingly talented Indians whom I would choose to work with in a heartbeat. I'm not trying to reinforce any sterotypes or discriminatory policies.
What I am trying to say is caveat emptor. If a thing seems too good to be true, it probably is. Sure, you can get engineering labor abroad for 10 cents on the dollar. But in many cases, you get what you pay for.
And finally, there are countless qualified engineers in AMERICA who need jobs. If a foreign individual or group has skills you can't find here, then fine, bring them here. But in the long run, you hurting yourself, your company, and your fellow Americans by trying to save a buck abroad. It ain't worth it.
Honestly, I wasn't aware of that... I'm somewhat scandalized that there isn't a big warning banner in the ports collection about that (they usually make you jump through hoops before installing patently insecure software).
Can you point us to some more informatiion regarding exploits for the most recent version of uw-imapd?
1. As a hiring manager, unless you go to a school I've heard of, in an English-speaking country, I'm probably not going to think very highly of your degree. Honsetly, for most geek jobs, the cultural diversity factor you'll gain is rather irrelavent. If you end up doing some important work or publishing in major journals, then you might be OK.
2. From a pragmatic perspective, you're going to end up spending more money (tuition, exchange rates, visas, long distance, airfare) and at best get the same education you'd get here.
3. You need to consider what you're going to do with the degree. If you're shooting for a terminal MS (i.e., not going on to a PhD), then what you're basically doing is getting advanced job skills training -- IMHO, it's best to get that in the US so that you're on the same page as the rest of us.
If you're going to do a PhD, either in Europe or back here, then the argument is different... If you work with a prestegious research group or professor in Europe, and produce some results, then you may be more attractive to Doctoral programs in the US. Then again, unless you're shooting for a career in academe, you'll most likely get out faster if you do your MS and PhD at the same university in the US (where language and cultural bullshit won't be an issue).
Personally, I thank my lucky stars that I stuck it out and got an MS... I'm a much better engineer for the experience and it's gotten me more than one job. I tailored my graduate program in such a way that if I decided to continue on in a PhD program I'd be in good shape, but also such that if I bailed with an MS I'd still have a lot of useful content under my belt. I suggest that you do the same.
4. Another person suggested moving to Europe for good, given the job market here. That's not the choice I'd make, but it's a resaonable suggestion. If you think that you'll want to work in Europe or work at an international company doing business in Europe, then doing some graduate work over there, even if it's only for a semester or two, sounds like a great idea.
5. One last thing to consider is that two jobs after graduation, the school you went to, and even the type of degree you have (MSCSE, MSCS, MSCSEE, etc) doesn't really matter. The fact that you have an MS combined with your work experience will be what gets you the interview. If the MS is from a big-name CS department, that can't hurt either, but it won't be a deciding factor.
I've been running uw-imapd on a FreeBSD 5.0 system, along with sendmail (latest and greatest) for about the last 1.5 years with zero problems. Depending on the size of your company, this may or may not be a good solution. Please bear in mind that this is my personal mail server -- it serves exactly one account.
Plusses:
o Absolutely dirty simple to set up -- no config files, no settings, just dump the port on, add a line to/etc/inetd.conf, and you're good to go o Resonably secure; supports SSL o Also supports POP3 and POP3 over SSL
Minuses:
o Each account needs a corresponding user on the system (you can, however, block login, I believe, to those users, such that they can not actually log into the system o Administration requires adding accounts on the system and FS-level quotas (if you care) o No fancy options or web/GUI's -- for me this is a plus, but it depends on how fancy your setup needs to be.
I've heard very good things about both Courier and Cyrrus but decided against them for my own use for a variety of reasons (mostly complexity).
Depending on your group size, uw-imapd may or may not be the right choice for you. Personally, however, I'd recommend running your mail server on an honest-to-god production-grade OS, like Free/Open BSD or a good Linux distro. And put it behind a good firewall. Gentoo is pretty cool, but mail MUST ALWAYS work, and to me that means running a production-quality, bullet-proof OS.
You can disable the HTTP port by turning off "Remote Management" on many Linksys devices (I use a BEFSR41). I'm not aware of TFTP ever being open on the outside on Linksys, but other boxes may vary.
And you're right, your firewall isn't going to let in a packet sourced from its inside interface. Well, most of the time. Some of the cheaper boxes, e.g., the older Netgear and D-Link boxes, do allow this routing path. You're correct: This path should not be allowed, as it may allow a mischevious outsider access to your network.
I'm pretty happy with the security provided by the Linksys NAT's. I've read in a couple places that NAT's don't really give you any security, but I find this to be false. All of the security probes I've run on my system come back with all green lights -- i.e., I'm secure. Does anyone have an explaination why such a configuration wouldn't be secure?
The 192.168 and 10 networks are functionally equivalent except that the 10 network is class A and the 192.168 is class B (i.e. 10 is bigger).
You will find that many off-the-shelf devices, like NAT/Routers from Linksys, Netgear, etc. use 192.168.x.x by default; some of them don't let you use anything else (I think Linksys locks you in to 192.168, but you can change the lower two octets).
I personally use a 10.x.x.x network in my test lab at work, because it allows me to choose network addresses that make sense and are somewhat human-readable. If you're setting up a network for a business, it might make sense to use a 10 network just for expandibility. Then again, if you need more than 64k addresses, you probably have bigger problems to deal with.
One thing I like about the 10 networks is that when you see their addresses scream across a packet dump, you can immediately recognize them as "fake" addresses.
One security/network citizenship point (assuming that your 10 or 192.168 network is behind a NAT connected to the outside world): your firewall/router should NEVER pass packets destined to or accept packets sourced from a fake address range (10/24, 192.168/16, etc.). This can lead to evil attacks, garbage traffic on or out of your network, and a whole host of problems.
I inadvertently flooded my company's T1 line while running a test because our sysadmins hadn't configured our firewall to block outbound packets destined to a 10 address. A bug in a server I was testing caused it to send data back to the wrong address and our router happily sent the data out over the T1. No major harm was done, but a few people couldn't read their Slashdot until we discovered what the problem was.
Bottom line: choose what works for you (which may be either address range).
Re:My Cellphone is Cool....no really.
on
Flaming Cellphones
·
· Score: 3, Informative
Or the battery shorts out internally, due to shoddy materials/construction. The phone may be in fine working order, but the battery can still short out.
Remember that the granularity (precision) of your "ping" times may be somewhat limited by the precision of your computer's clock. On many systems, these times are only accurate to about 10ms.
And, of course, latencies change diurnally, i.e., over time, due to the changing traffic patterns throughout the day and week. Traffic levels through major ISP's will be higher during the day because of people surfing porn^H^H^H^H the web at work, but they may be higher for cable modem/DSL users during the evening, when home users are downloading porn^H^H^H^H their mail and surfing.
To get a fairly clean picture of your actual latencies, you should sample several times an hour for about a week and graph the results. Or, if you're feeling less geeky, run the test at 2am, when the network is likely unloaded.
Your post states that latency and throughput are unrelated. For TCP connections (FTP, HTTP, IMAP, POP, and many games), this is absolutely not true.
The maximum possible throughput of a TCP connection is one "window" of data per round-trip time. The "window" size is essentially the amount of unacknowledged (ACK'ec) data that can be outstanding. This is often called the bandwidth-delay product, I think.
What you need to take away from this is that even if you had infinite bandwidth between you and your peer, the throughput of a single TCP connection is upper-bounded by the delay product. For example, if your window size is 32KBytes (I'm going to use 32,000 to make the numbers prettier) and the round-trip time is 100ms, then you can transmit (or receive) at most 32KB * 10 = 320KB per second. To go faster, you have to either increase the window size (which consumes more memory) or decrease the round-trip time (which is sometimes impossible, since the speed of light is a constant, or so my physicist friends claim).
A couple other points.
You're probably not capable of noticing the difference between 10ms and 20ms in terms of response time for interactive applications, including online gaming. if it were 10ms vs 100ms or 200ms, then yes, but 10ms is less than one refresh interval on your monitor, so you really can't "see" the difference.
As far as VoIP (IP telephony) and other multimedia network applications are concerned, again, you must consider the end-to-end latency (one-way delay) and/or the round-trip time, not the latency between you and some arbitrary router at your ISP.
The phone companies spec their systems (or so I've heard) such that the *round trip* latency for a domestic call is always less than or equal to 100ms. We're talking POTS here, not cell service, which experiences higher latencies.
I work on VoIP software; in an IP call (both ends are IP clients), it's very hard to keep the *one way* latency below about 100ms, if you're lucky, even if both clients are on a LAN. This is because you have to have various buffer and jitter compensation delays so that the sound quality is acceptible under somewhat adverse network conditions. In a typical call across the internet, 200ms one-way latency, IMHO, would be considered quite good.
So your 20ms intra-ISP latency (vs. the 10ms that your friend reports) is in the noise.
Oh, I should also mention, for completeness, that packet loss (or even reordering, which is more common that you may realize) can *really* hurt both TCP and VoIP (which usually uses UDP) performance/quality. This gets into some messier technical issues... basically, though, if your DSL isn't lossy, and you're getting 20ms intra-ISP latencies, you're doing as well or better than most of us.
Your friends who are running on 56k modems, who eat 200ms just to get their packets to the ISP's router on the other side of the PSTN are really going to be hurting:)
You make a good point... apt and rpm do a nice job, perhaps as good or possibly better than ports.
One place where ports has an advantage, however, IMHO, is that the "database" of available packages lives on your local filesystem... you don't have to go searching around the web for the package you want, and you don't need a GUI to fetch and install packages.
Yes, I know, rpm and apt have command-line modes, but I'm not aware of a way to "browse" collections of these types of packages without a GUI. I'm usually more at home in a console window than a clunky, slow X app.
I guess we're at the point of arguing matters of taste, which is usually fruitless. FreeBSD is a wonderful OS, as is Linux, but it doesn't get as much press. The ports collection is something the FreeBSD team can and should be proud of.
I've been a FreeBSD fan for several years now. Had I been smarter when I was younger, I would have been a fan even longer than that:)
FreeBSD, IMHO, comes pretty darned close to Linux in terms of ease of install and, in many ways, exceeds it in ease of use. Configuration files are where you expect them to be. Utilities are named what you expect them to be named.
And, to tie into this article, the ports collection provides a wealth of great software. There's no issue as to which flavor of Linux you have... if you're running FreeBSD, the port will generally work on your system, whether you compile it from sources or download the precompiled package from one of the ftp mirrors.
Kudos to the FreeBSD team for all their hard work and for giving us such a stable, reliable, useful platform to develop and play on.
You have to be careful to find a card that uses a chipset that is supported by hostap. As you mention, the only chipset (that I'm aware of) that does is the PRISM-x chipset. Luckily, this is a very good chipset, from what I've seen. It works with hostap in FreeBSD (5.1, at least) was well.
The other chipsets won't work with hostap. Look in the man pages for hostap for a list of all the cards that it supports -- it's quite a long list.
Note also that, if you go this route, you'll have to set up your own DHCP, NAT, etc., and make sure that your system is "hardened" so that you don't have a big security hole in your network (or put it behind some other firewall).
This is a good solution for us Linux/UNIX geeks, but not for everyone.
Personally, I have a 340-series (802.11b) Cisco AP at home, which has been running just fine for about 3 years now. The only real maintenence I've done to it was to upgrade the firmware sometime last year. The only problem with the Cisco boxes is that they're a little expensive; you probably can get one pretty cheaply on Ebay.
At work, we have several Linksys AP's and I have a Linksys WET11 wireless-to-ethernet bridge at home. I have found Linksys's equipment to be quite reliable and reasonably-priced. Their firmware releases used to be a little flakey about 2 years ago, but their latest couple releases have proved very stable.
I don't think you could go wrong with either Linksys or Cisco.
Slashdot Mirror
I'm a Comcast cable modem subscriber. As far as I know, I'm not on their black list yet. However, I find the very notion of a black list fundamentally unacceptable.
I'm paying for a service which is supposed to give me a certain quantity of upstream and downstream bandwidth (384/3.5 in my case). As far as I'm concerned, I should be able to use every last kilobit of that allocation, 24 hours a day, 7 days a week, if I want. I don't, and I don't ever plan to, but I should have the option.
The problem that the article glosses over is that the consumer-grade ISP's are massively oversubscribed. Yeah, your transfer rates are theoretically what they say they are, but you're sharing that pipe with 5000 of your neighbors. And the ISP's often don't have enough bandwidth at their headends to support the triburary peak busy hour traffic. They need to fix this or stop making such hyperbolic claims about the speed and capacity of the service they offer. And if they are going to limit your total bandwidth consumption, then they need to tell you how much you get and allow you to monitor how much you have left (and even allow you to buy more).
To be fair, Comcast has reasonable prices (I pay about $43/month for my service) and once I got everything working, I've had excellent service for going on two years. From an availability/uptime standpoint, they do great. The value is quite good. Being secretive about their bandwidth consumption policies is not good.
This all highlights the point that an increasing number of users require very large amounts of bandwidth in their homes (for whatever reasons). The ISP's need to realize this and impliment solutions that enable this level of service.
The origional IBM PC keyboards, those heavy, rather clunky clickety-click input devices from the 80's and early 90's are, IMHO, the best computer keyboards ever made.
:)
They were designed to have a touch and feel very similar to the IBM Selectric (sp?) typewriters. [Typewriters are an ancient device which uses an ink ribbon and an impact device to print letters on paper.] Well-seasoned executive assistants will tell you that the Selectric's were the best electronic typewriters ever made -- this is due largely to the touch and feel of the keyboard.
The old IBM keyboards were also quite sturdy... I'd say they weighed in at around 5 lbs (2.4 kg) or so. They make handy weapons, too, for pummeling over-zealous managers into submission
You can still find these keyboards at flea markets, computer shows, and on eBay. They'll be used, and you may have to get an adapter from the large DIN plug to PS2. Most of them didn't have the goofy Windows keys either, but who cares?
That failing, your next best bet is to go to your local computer superstore and try out all their keyboards. I personally avoid ones that do not have the standard configuration for the arrow keys and insert/delete.../page down, since that messes with my muscle memory.
Good luck!
I'm fortunate enough to have a job where I can pretty much come and go as I please, so long as my work gets done. I realize that this is not the case in many companies, but my current company, and my last two companies (Cisco and IBM) have all been pretty good about this.
I think that nit-picking about when developers get into work is just plain pointless. Obviously, if you have to be at various meetings or if you have a customer-facing role, your schedule will be more restricted. But barring those circumstances, what difference does it make if you work 9-5, 10-6, 11-7, or 12-8? As long as you get your work done and your schedule doesn't interfere with the normal flow of business and work at your company, who the hell cares?
My work schedule is largely dictated by my sleep schedule, which is dictated by my body. I function best by sleeping from about 1am to 9:30 or 10am. (11am is better still!). Trying to move that around just makes me less productive, more grumpy, and unhealthy in general. I have friends who have vastly different sleep schedules from me... some like to get up at the butt-crack of dawn, and some sleep mostly during daylight hours. Clearly, you can take this too far... there are job functions that require you to actually be in the office at the same time as your co-workers. But that still allows for a great deal of flexibility.
And remember, flex means flex. If your normal work week is 40 hours, and you end up staying at work late one night fixing a bug, then you should be able to get in late or leave early another day in the near future. Aa long as the system is not abused, it works great and makes for happy workers and optimal productiviy.
The exception to all this is that I have a standing agreement with my supervisors that if they need me in early or need my to stay late, I'll happily comply. They don't ask this of me very often, but when they do, I drink an extra cup or two of coffee and deal with it. So they know I'm always available in emergency situations (even on weekends, as necessary) and I know that if I want to take off early on a Friday or sleep in after a party, I'm good to go.
Again, my style may not be your style, but the general principles, I think, make for a very satisfying work environment.
I'm not sure that "insecure by design" is quite fair to the hard-working folks who developed this near-ubiquitous MTA.
A fairer assessment is that, when sendmail was designed, security was not as big an issue as it has become today. And in their defense, they do seem quite good about notifying people when vunerabilities arise and releasing fixes as quickly as possible.
That being said, sendmail is a pain in the ass. You have to remember that when sendmail was developed, there were many different mail protocols (besides SMTP), and sendmail had to support all of them -- this is why sendmail config files are so darned complex and unreadable. The vast majority of those have faded into obscurity, so subsequent products, like Postfix, can be much simpler and less complex and, thus, more likely to be secure. For a long time, sendmail was the only choice for a real MTA, but I think Postfix has proven itself a worthy successor.
Redhat has their up2date service... however, you have to pay for it. It definitely notifies you about updates for each of your systems. Supposedly, you can schedule maintenence via their website for all of your machines. I used it for a while on a trial basis, and it seemed to work OK.
:)
However, I object to having to pay for free software
Anyone want to get together and work on an open-source auto-update package?
The CCNA certification covers a rather broad, albeit not very deep (IMHO) range of networking concepts and technologies, protocols, etc., as I'm sure you've read in the course descriptions. I don't have any of the CC* certifications myself, but I have been working in networking since about 1998, and I worked at Cisco for about 3.5 years.
:)
I think you should go ahead and take the course. Let me give you a couple reasons why.
1. If you're not knowledgable about networking, you should be. Networking and the Internet in general, as we all now, are increasingly critical technologies for software engineers in almost all businesses. You should have at least a high-level understanding about how and why they work; the more you know, the better you will be.
2. At Cisco, CCNA's weren't really considered very useful... you were expected to know or learn whetever you needed to know for your job, certification or not. However, many companies encourage or require that their network administrators and other IT folks get CCNA's, which indicates to me that they place some value in the skill-set implied by having such a certification. Personally, if I'm the hiring manager and I care about your networking knowledge, I'm going to quiz you on networking anyway, and not trust that the CCNA means anything in particular.
Having a CCNA can't possibly hurt you. Even if your work isn't related to networking, it shows that you have a diversity of skills and interests, and that you have sensitivity to issues outside of your core skill set. It also means that I might be able to use you on networking-related projects, which increases your value to me as an employee.
3. Hell, you may find, as I did, that networking is really fun stuff and that you'd like to persue it further. No loss there either!
Let me close by saying that passing the CCNA test only means that you knew a certain set of material on a particular day. It doesn't make you a networking expert. If you don't use those skills, you'll lose them, just like anything else. Keep reading about new technologies, and, if you can, fiddle with networks from time to time. Keep up your intuition and troubleshooting skills. Knowing how to debug network problems comes in handy at the strangest times
I used to work at a major network hardware company. They had outsorced a large chunk of QA work to some contractors in India -- some script-writing, some regression tests, and other sundry tasks. Without necessarily making any broad generalizations about Indian contractors or foreign contracting in general, let me share my experiences and impressions with you, in the hopes that you won't make the same mistake that my company made.
1. Time zone: I was on the East Coast (EST/EDT). I beleive that India was about 12 hours away from us, give or take. This meant that basically anything you asked them to do took at least 1 full working day, since by the time I got into work, they were in bed. You can just imagine the problems this caused when deadlines or other time-critical matters were involved.
2. Language: Again, without making any broad generalizations... Their English sucked. It was nearly impossible to communicate with them on the phone and their written English was less than acceptible. Also, based on serveral very frustrating experiences with the whole group, I concluded that their comprehention of written English was equally poor. We finally found a guy there who could understand English well enough to explain things to the rest of the group, but even then, my confidence level was quite low.
3. Work Ethic/Product: Both the group in question and several other Indians I've worked with since then have had some similar issues w/r/t how they worked and what they produced. Again, not to generalize... If you give them very clear, step-by-step instructions to perform a discrete task, they generally will perform the task quite thoroughly. However, if the procedure requires any deviation from the norm or any creativity or synthesis, you're better off doing it yourself, because they'll never figure it out.
We also had problems getting them to listen to anyone other than management -- they basically ignored team lead's, including myself.
In their defense, I understand that the education system in India teaches them to work this way; it has a large focus on rote memorization and obeyance of authority. That's great, and it seems to work for them. However, that's not how we work in the US, and folks who have gone to US (or European or Chinese) schools and worked with others of the similar ilk will get very frustrated trying to mesh with thinking processes that are polar opposites of their own. Furthermore, I find this thinking process thoroughly unproductive and pretty much useless in an Engineer.
Now, I'm just waiting for someone to write back flaming me for being some kind of racist, so let me state once more that I am relating my personal experiences with certain Indians. I went to grad school with several amazingly talented Indians whom I would choose to work with in a heartbeat. I'm not trying to reinforce any sterotypes or discriminatory policies.
What I am trying to say is caveat emptor. If a thing seems too good to be true, it probably is. Sure, you can get engineering labor abroad for 10 cents on the dollar. But in many cases, you get what you pay for.
And finally, there are countless qualified engineers in AMERICA who need jobs. If a foreign individual or group has skills you can't find here, then fine, bring them here. But in the long run, you hurting yourself, your company, and your fellow Americans by trying to save a buck abroad. It ain't worth it.
For the current version/patch-level? Really?
:)
Honestly, I wasn't aware of that... I'm somewhat scandalized that there isn't a big warning banner in the ports collection about that (they usually make you jump through hoops before installing patently insecure software).
Can you point us to some more informatiion regarding exploits for the most recent version of uw-imapd?
Thanks
1. As a hiring manager, unless you go to a school I've heard of, in an English-speaking country, I'm probably not going to think very highly of your degree. Honsetly, for most geek jobs, the cultural diversity factor you'll gain is rather irrelavent. If you end up doing some important work or publishing in major journals, then you might be OK.
2. From a pragmatic perspective, you're going to end up spending more money (tuition, exchange rates, visas, long distance, airfare) and at best get the same education you'd get here.
3. You need to consider what you're going to do with the degree. If you're shooting for a terminal MS (i.e., not going on to a PhD), then what you're basically doing is getting advanced job skills training -- IMHO, it's best to get that in the US so that you're on the same page as the rest of us.
If you're going to do a PhD, either in Europe or back here, then the argument is different... If you work with a prestegious research group or professor in Europe, and produce some results, then you may be more attractive to Doctoral programs in the US. Then again, unless you're shooting for a career in academe, you'll most likely get out faster if you do your MS and PhD at the same university in the US (where language and cultural bullshit won't be an issue).
Personally, I thank my lucky stars that I stuck it out and got an MS... I'm a much better engineer for the experience and it's gotten me more than one job. I tailored my graduate program in such a way that if I decided to continue on in a PhD program I'd be in good shape, but also such that if I bailed with an MS I'd still have a lot of useful content under my belt. I suggest that you do the same.
4. Another person suggested moving to Europe for good, given the job market here. That's not the choice I'd make, but it's a resaonable suggestion. If you think that you'll want to work in Europe or work at an international company doing business in Europe, then doing some graduate work over there, even if it's only for a semester or two, sounds like a great idea.
5. One last thing to consider is that two jobs after graduation, the school you went to, and even the type of degree you have (MSCSE, MSCS, MSCSEE, etc) doesn't really matter. The fact that you have an MS combined with your work experience will be what gets you the interview. If the MS is from a big-name CS department, that can't hurt either, but it won't be a deciding factor.
I've been running uw-imapd on a FreeBSD 5.0 system, along with sendmail (latest and greatest) for about the last 1.5 years with zero problems. Depending on the size of your company, this may or may not be a good solution. Please bear in mind that this is my personal mail server -- it serves exactly one account.
/etc/inetd.conf, and you're good to go
Plusses:
o Absolutely dirty simple to set up -- no config files, no settings, just dump the port on, add a line to
o Resonably secure; supports SSL
o Also supports POP3 and POP3 over SSL
Minuses:
o Each account needs a corresponding user on the system (you can, however, block login, I believe, to those users, such that they can not actually log into the system
o Administration requires adding accounts on the system and FS-level quotas (if you care)
o No fancy options or web/GUI's -- for me this is a plus, but it depends on how fancy your setup needs to be.
I've heard very good things about both Courier and Cyrrus but decided against them for my own use for a variety of reasons (mostly complexity).
Depending on your group size, uw-imapd may or may not be the right choice for you. Personally, however, I'd recommend running your mail server on an honest-to-god production-grade OS, like Free/Open BSD or a good Linux distro. And put it behind a good firewall. Gentoo is pretty cool, but mail MUST ALWAYS work, and to me that means running a production-quality, bullet-proof OS.
Hmm... well, that's odd. I'll have to try that on my box when I get home.
FYI, there's a new firmware out (for BEFSR41), circa June 20-something 2003. Nothing much changed, so far as I can tell.
You are (technically) correct.
/8 networks class A, /16 networks class B, and so on.
:)
Being a somewhat younger lad, I've gotten used to calling
Kind of ironic, since almost all routing now is classless.
Anyway, thanks for keeping me on my toes
You can disable the HTTP port by turning off "Remote Management" on many Linksys devices (I use a BEFSR41). I'm not aware of TFTP ever being open on the outside on Linksys, but other boxes may vary.
And you're right, your firewall isn't going to let in a packet sourced from its inside interface. Well, most of the time. Some of the cheaper boxes, e.g., the older Netgear and D-Link boxes, do allow this routing path. You're correct: This path should not be allowed, as it may allow a mischevious outsider access to your network.
I'm pretty happy with the security provided by the Linksys NAT's. I've read in a couple places that NAT's don't really give you any security, but I find this to be false. All of the security probes I've run on my system come back with all green lights -- i.e., I'm secure. Does anyone have an explaination why such a configuration wouldn't be secure?
The 192.168 and 10 networks are functionally equivalent except that the 10 network is class A and the 192.168 is class B (i.e. 10 is bigger).
You will find that many off-the-shelf devices, like NAT/Routers from Linksys, Netgear, etc. use 192.168.x.x by default; some of them don't let you use anything else (I think Linksys locks you in to 192.168, but you can change the lower two octets).
I personally use a 10.x.x.x network in my test lab at work, because it allows me to choose network addresses that make sense and are somewhat human-readable. If you're setting up a network for a business, it might make sense to use a 10 network just for expandibility. Then again, if you need more than 64k addresses, you probably have bigger problems to deal with.
One thing I like about the 10 networks is that when you see their addresses scream across a packet dump, you can immediately recognize them as "fake" addresses.
One security/network citizenship point (assuming that your 10 or 192.168 network is behind a NAT connected to the outside world): your firewall/router should NEVER pass packets destined to or accept packets sourced from a fake address range (10/24, 192.168/16, etc.). This can lead to evil attacks, garbage traffic on or out of your network, and a whole host of problems.
I inadvertently flooded my company's T1 line while running a test because our sysadmins hadn't configured our firewall to block outbound packets destined to a 10 address. A bug in a server I was testing caused it to send data back to the wrong address and our router happily sent the data out over the T1. No major harm was done, but a few people couldn't read their Slashdot until we discovered what the problem was.
Bottom line: choose what works for you (which may be either address range).
Or the battery shorts out internally, due to shoddy materials/construction. The phone may be in fine working order, but the battery can still short out.
Dial 911 to report the fire.
She must have dialed a 666 number... Or perhaps it was Bill Gates calling. >:-)
Remember that the granularity (precision) of your "ping" times may be somewhat limited by the precision of your computer's clock. On many systems, these times are only accurate to about 10ms.
And, of course, latencies change diurnally, i.e., over time, due to the changing traffic patterns throughout the day and week. Traffic levels through major ISP's will be higher during the day because of people surfing porn^H^H^H^H the web at work, but they may be higher for cable modem/DSL users during the evening, when home users are downloading porn^H^H^H^H their mail and surfing.
To get a fairly clean picture of your actual latencies, you should sample several times an hour for about a week and graph the results. Or, if you're feeling less geeky, run the test at 2am, when the network is likely unloaded.
Your post states that latency and throughput are unrelated. For TCP connections (FTP, HTTP, IMAP, POP, and many games), this is absolutely not true.
:)
The maximum possible throughput of a TCP connection is one "window" of data per round-trip time. The "window" size is essentially the amount of unacknowledged (ACK'ec) data that can be outstanding. This is often called the bandwidth-delay product, I think.
What you need to take away from this is that even if you had infinite bandwidth between you and your peer, the throughput of a single TCP connection is upper-bounded by the delay product. For example, if your window size is 32KBytes (I'm going to use 32,000 to make the numbers prettier) and the round-trip time is 100ms, then you can transmit (or receive) at most 32KB * 10 = 320KB per second. To go faster, you have to either increase the window size (which consumes more memory) or decrease the round-trip time (which is sometimes impossible, since the speed of light is a constant, or so my physicist friends claim).
A couple other points.
You're probably not capable of noticing the difference between 10ms and 20ms in terms of response time for interactive applications, including online gaming. if it were 10ms vs 100ms or 200ms, then yes, but 10ms is less than one refresh interval on your monitor, so you really can't "see" the difference.
As far as VoIP (IP telephony) and other multimedia network applications are concerned, again, you must consider the end-to-end latency (one-way delay) and/or the round-trip time, not the latency between you and some arbitrary router at your ISP.
The phone companies spec their systems (or so I've heard) such that the *round trip* latency for a domestic call is always less than or equal to 100ms. We're talking POTS here, not cell service, which experiences higher latencies.
I work on VoIP software; in an IP call (both ends are IP clients), it's very hard to keep the *one way* latency below about 100ms, if you're lucky, even if both clients are on a LAN. This is because you have to have various buffer and jitter compensation delays so that the sound quality is acceptible under somewhat adverse network conditions. In a typical call across the internet, 200ms one-way latency, IMHO, would be considered quite good.
So your 20ms intra-ISP latency (vs. the 10ms that your friend reports) is in the noise.
Oh, I should also mention, for completeness, that packet loss (or even reordering, which is more common that you may realize) can *really* hurt both TCP and VoIP (which usually uses UDP) performance/quality. This gets into some messier technical issues... basically, though, if your DSL isn't lossy, and you're getting 20ms intra-ISP latencies, you're doing as well or better than most of us.
Your friends who are running on 56k modems, who eat 200ms just to get their packets to the ISP's router on the other side of the PSTN are really going to be hurting
You make a good point... apt and rpm do a nice job, perhaps as good or possibly better than ports.
One place where ports has an advantage, however, IMHO, is that the "database" of available packages lives on your local filesystem... you don't have to go searching around the web for the package you want, and you don't need a GUI to fetch and install packages.
Yes, I know, rpm and apt have command-line modes, but I'm not aware of a way to "browse" collections of these types of packages without a GUI. I'm usually more at home in a console window than a clunky, slow X app.
I guess we're at the point of arguing matters of taste, which is usually fruitless. FreeBSD is a wonderful OS, as is Linux, but it doesn't get as much press. The ports collection is something the FreeBSD team can and should be proud of.
I've been a FreeBSD fan for several years now. Had I been smarter when I was younger, I would have been a fan even longer than that :)
FreeBSD, IMHO, comes pretty darned close to Linux in terms of ease of install and, in many ways, exceeds it in ease of use. Configuration files are where you expect them to be. Utilities are named what you expect them to be named.
And, to tie into this article, the ports collection provides a wealth of great software. There's no issue as to which flavor of Linux you have... if you're running FreeBSD, the port will generally work on your system, whether you compile it from sources or download the precompiled package from one of the ftp mirrors.
Kudos to the FreeBSD team for all their hard work and for giving us such a stable, reliable, useful platform to develop and play on.
Well, when they do a 360 panorama and I can't see a single building, telephone pole, or road, that qualifies as BFE nowhere to me :)
You're probably right, though. If one lives in cities too long, one begins to thing that everything everywhere looks like a city.
The lack of tarmac density is a good thing though... if means we don't have to drive too far to get away from "civilization".
What I found odd about the confluence points was that almost none of them where in populated areas. It just seems a little strange.
I guess it just goes to show that no matter how overpopulated the world seems, there is still a lot of wide-open space out there.
You have to be careful to find a card that uses a chipset that is supported by hostap. As you mention, the only chipset (that I'm aware of) that does is the PRISM-x chipset. Luckily, this is a very good chipset, from what I've seen. It works with hostap in FreeBSD (5.1, at least) was well.
The other chipsets won't work with hostap. Look in the man pages for hostap for a list of all the cards that it supports -- it's quite a long list.
Note also that, if you go this route, you'll have to set up your own DHCP, NAT, etc., and make sure that your system is "hardened" so that you don't have a big security hole in your network (or put it behind some other firewall).
This is a good solution for us Linux/UNIX geeks, but not for everyone.
Personally, I have a 340-series (802.11b) Cisco AP at home, which has been running just fine for about 3 years now. The only real maintenence I've done to it was to upgrade the firmware sometime last year. The only problem with the Cisco boxes is that they're a little expensive; you probably can get one pretty cheaply on Ebay.
At work, we have several Linksys AP's and I have a Linksys WET11 wireless-to-ethernet bridge at home. I have found Linksys's equipment to be quite reliable and reasonably-priced. Their firmware releases used to be a little flakey about 2 years ago, but their latest couple releases have proved very stable.
I don't think you could go wrong with either Linksys or Cisco.