I thought that there were providers that would let you "hardcode" a location into their service -- ie, if you were using it at home, you put in your home address, and then that info is available to 911. If you're moving around, it's obviously going to be more difficult, but basically the same as a cell phone is now. At the least they know who you are.
as my prompt. I work on many different systems (it's not uncommon for me to have 3 or 4 different sessions to different machines), so the hostname is almost a requirment. Username is a bit handy as well.. and it doesn't take up lots of space, so that's ok.
I also started using \w as my path (which prints the full path) simply because it would be too easy to lose track without it. When you come back to a window and it says "[root@ws005:bin]# " that doesn't really tell you a lot. I much prefer to see "[root@ws005:/usr/bin]#" or "[greg@hydrogen:/usr/local/someprog/bin]$".
Also handy is that the prompt is a valid source/target for scp or rsync.
2) production code is not documentation on the APIs that it uses. APIs have their own documentation, the reader either is familiar with it, or can find documentation.
I should have been more clear on this. I agree exactly with someone else that replied to this.. in this example, SDL_GetTicks() is not a clear name. If it was SDL_GetCurrentTicks() or something along those lines, fine. But since it's unclear, my "// now" hint is enough that I don't have to spend a few minutes looking for and searching through documentation or code to find a simple answer.
6) NEVER put actual values in comments. For example:
Normally I'd agree with this, but one thing I sometimes do is put translations.
update_interval = 50400;// 14 hours
This just saves me later wondering what "50400" is.
So your free music is DRMed to death? You're also gonna have to pay to put your "free" tunes on a DAP? Free as in beer locked in a safe I guess.
I wonder if some day a company will offer DRM-less music. I'd be willing to pay for that. When I get locked into using a crappy player, can't transfer music to another machine (such as my media jukebox running MPD that is controlled from a web browser and plays on my stereos), and possibly lose all access to it if the company goes under, I'm just not willing to pay for that "privledge".
Rather than just see words, I'd rather see real-life applications of these practices. For starters, here's typically how much I comment my code:
tmp = last_update;// tmp = last update time
last_update = SDL_GetTicks();// Set the last update time to now
tmp = last_update - tmp;// tmp = difference between now and last update
fps_timer += tmp;// Increase our fps millisecond timer
fps_counter++;// Increase our frame count
There's also something as far as too much commenting. Don't get me wrong, I can't stand uncommented code. I learnt, like most people, the hard way -- go back to edit something I did 6 months ago, and have no idea what's happening.
But I don't think this is useful:// tmp = last update time. You've just spelled out in english what tmp = last_update; says in code. Comments don't add anything if you can just read the code and figure it out. If anything, it's a waste of time.
Here's my version of your same section
// find the time since our last update
tmp = last_update;
last_update = SDL_GetTicks();// now
tmp = last_update - tmp; // add time and increment counter
fps_timer += tmp;
fps_counter++;
This isn't really the greatest example, but I like to comment sections of code. The details can be read by looking through the code, with "hints" as needed (for example, reminding me that SDL_GetTicks() is the current time).
Well commented blocks mean you can skim through the code, getting a quick overview of what's happening, without having to read in much detail.
// find matching entry in hash table while (.... ..... ..... }
You don't have to care about the details of the look, you just know by the time you hit the } you've found what you wanted.
Don't take this personally or anything. Your code is very readable.. there's just lots of extra comments (granted, I've seen worse) that are really just not worth putting in.
(also, proper indenting is as, if not more, important.. of course,/. is butchering my indenting.. so please don't harass me about that because i couldn't agree with you more;) )
Try harder, PSU provides email for 130,000+ users (generally around 6 million emails a day) without a RBL. RBLs are a bad solution looking for a problem, there are much better ways to deal with spam that are not run by clueless zealots.
Okay, let me add to that then. It's not pratical on our scale to run it without RBL's. We were getting at least one dictionary attack a day, and it was getting to the point where the system couldn't even keep up and we were getting several thousand messages waiting in the queue.
We were investigating adding another system to run as a mail server or gateway, upgrading our existing system, or offloading mail processing to another service. I'd love to have a dedicated mail server, or multiple systems load balanced.. but the reality is on a small scale it's not pratical to do. Adding just a 1U gateway doubles our colocation costs, means more admin work to keep them updated, and means spending more money on a system just to block spam.
So it's OK to blacklist a little guy that has a misconfigured/hacked email server that is spitting out spam, but if a big fish does this, we should justify and make excuses for them??
NO -- it's not ok to blacklist the little guy either.
If they're misconfigured/hacked, and spitting out spam, sure.. blacklist them (whether they're AOL or a little isp). Of course, you should probably send a message to abuse@ their domain trying to inform them..
Too many lists don't check though. They get a complaint, and bam, blacklist. I run a small web/mail server (300 domains, 16 IPs), and this is highly annoying. We've been blacklisted before because someone complained about a legitimate mailing list they were on. No double-checking, no investigation into the complain, we just got blacklisted immediately.
Most recently, we were blacklisted by SORBS because another system that shares colocation with our server was hacked. Immediately, they blacklisted the entire subnet. This affected us, and numerous other customers that have no affiliation other than sharing colocation space.
I noticed we were on the list when someone in the office complained about not being able to send mail to an address she could send to a couple hours earlier. Upon looking into it, we eventually found out that teh entire subnet was blocked (and we couldn't even request to remove the block), so we contacted our ISP. They told us they had just discovered that hacked system and disconnected it, and tried to get the block removed from SORBS.
In all, our ISP had found and disconnected the system within 3 hours of it being hacked, yet we were on the list at least 24 hours. During this time, none of our customers can send mail to anyone with a provider using SORBS. Our server was fine, their servers are fine, but because of a completely unrelated incident with unrelated people, it affects hundreds more.
The big problem is, it's basically impossible to run a mail server without using RBL's (we tried).. you just get hammered. RBLs are definately useful, but there are too many run by over-zealous admins with basically an itchy trigger finger. Hopefully stunts like this will make people realize the problems with RBLs and maybe we can drop the ones that are run this way.
Programmers know too much about the inner workings of a system... and thus they will immediately think of all the reasons why an innovative idea (interface element or feature) won't work. But the naive user, not encumbered by such restrictive thinking, may propose powerful features and novel interaction schemes. Some of these won't work, and some really are too hard to code, but there are many gems.
As a programmer, this is something I try really hard to do -- step back, and forget everything I know about the backend. When coming up with a new concept, I ask myself "What is the optimal way this GUI would be implemented?" without any regard for how things are structured behind the scenes.. just thinking about how the interface should act. Sometimes I'll even draw out an interface on paper first, or do a quick non-working prototype to get a feel for it. (Note, I'm refering to the usability, not necessarily the end look.. though these are related, I'm not concerned with colors, positioning, etc, at this point).
Once I have the "best" interface I can think of, I then start figuring out how to apply that to my backend structure. Sometimes this involves making comprimises and changing from my optimal interface, but usually it is doable. The big difference is now the problem is simply a matter of figuring out "how do i represent data x as y?" which is a specific task, as opposed to trying to figure out how to manipulate data AND display an interface at the same time.
It's just a different perspective to take, which is really the important thing.
The harder part was re-wiring my house so that all the phones would work using voip (instead of just having one phone plugged into the Linksys router). Even this is not too bad: just disconnect your internal wiring from the Telco, and then plug the voip router into a wall-jack, so that all wall-jacks are now connected to it.
Here's another idea: if you want your POTS line as well as a voip line, phones only use two wires (red and green). Yellow and black are spare, and are often used to run a second line. If you hook up your ATA to the yellow/black pair, then you now have both lines running everywhere in your house.* Get a two-line phone, and you can access both lines (this may require adding an additional jack wired to yellow/black), or selectively you can wire yellow/black instead of red/green to any jack to make it use the second line.
(*: This is assuming that all 4 wires have been connected anywhere they split in the house. Most newer homes have all the phone jacks with one continous wire coming down to a central location, where it's connected to the telco demarc, but the old method was to daisy-chain or just randomly splice into a nearby wire to add a jack. If this was done improperly, or worse, yellow/black red/green were interconnected somewhere, it can fry your equipment and be very hard to track down. Make sure you know what you're doing before you try anything like this. If you blow your phones/ATA/computer/self up, I take no responsibility:) )
I can't tell you how many times I've had VOIP vendors approach me with their hair-brained notion of saving us money. The ridiculous per-line charge is where they start to fall on deaf ears with me. Our per-line cost with two PRIs is way lower than with VOIP. What, then if not cost savings, would inspire a change? Nothing that I can think of... some bells-n-whistles administration? Not going to offset the cost of equipment either since we own our phone stuff.
Sounds like a case of sales people blindly suggesting a solution without knowing your needs. VoIP is not going to beat a T1, because really, what the VoIP providers do is get a T1 (or a few..) and sell services through them. A T1 really remains the most cost effective way to get PSTN connectivity (well, there are probably other bigger pipes that I don't know anything about, but these are only going to be cheaper per-line). For a small business with only a few lines, VoIP can definately save money -- provided it's implemented properly with some kind of redundancy/backup so your SLA-less DSL line going down doesn't mean you can't get calls from your customers.
In a larger business, VoIP can save quite a bit of money. I've talked to people who have T1 interconnects between offices just for internal lines. By switching to VoIP over their existing T1 or fiber-based internet service, they can eliminate the monthly costs of two T1 lines (one at each location), and typically the small investment in PC hardware running asterisk is easily paid back within a couple months.
Going VoIP doesn't mean you can't use other technologies (analog lines, T1's,...). You get the best solution by taking the best each has to offer, using the best tool for the job.
Is the on site documentation good enough or are there other resources you would recommend?
voip-info.org is like the bible of the VoIP/asterisk world. I definately recommend browsing around there before getting started, and keeping it bookmarked while you're installing and configuring asterisk.
I'm actually one of the developers for AMP, which is the web GUI that asterisk@home uses, and one of the biggest things I see is that there's a lot of people that want to just jump in thinking they don't need to know anything to get started. I'm not sure why this is, but you most definately need to understand basic concepts of a PBX, and some telephone technology, and how asterisk itself works in relation to those things. Most definately do not setup a mission-critical phone system (and I'd argue that any phone system used in a business instanly becomes mission-critical) without testing - a lot - first. Some people even setup test systems in their homes before hand.. and since the entry cost is so low, this is entirely possible. It's hard to recommend how much and what method to use for testing, since it varies depending on the size of your install. voip-info has some deployment tips though, that are probably very useful.
After taking this into consideration, unfortunately, going through the local Ma Bell monopoly was still the cheapest and most reliable option for us (a business needing 3-5 phone lines).
Usually there are resellers that will get you a fully-featured POTS line at well below the cost of a line from Ma Bell. Bell Canada is the main carrier here, and I can get lines from either AllStream or Primus for several dollars less than Bell, and they include many features -- call/name id, hunt group, other stuff I don't use -- at less than the cost of a basic line from Bell.
We've been running on Asterisk for a couple of months now, and it's made an impact on our phone bills. Our telephone hardware was aging anyways, so we deployed Asterisk with all new (and low-cost) VoIP phones, at around the same price it would have cost to get a low-end, not very configurable non-VoIP system.
We have 4 incoming analog POTS (plain old telephone service) lines (one is dedicated to fax). We have two VoIP providers (mostly just for redundancy.. outgoing minutes are cheap). Long distance calls are routed through VoIP, and a maximum of two local calls will get routed through POTS lines before using Voip, which for the most part keeps a POTS line free for incoming calls. If our internet is down, long-distance calls simply fail over to the POTS lines, and if they're all used up it tells you "all lines are busy now", which is annoying but not any different than it would be without VoIP.
Since we just moved and were forced to change our number, I'm waiting on getting our old number switched to a VoIP provider. Right now it's call-forwarded to our new number, but when it goes VoIP, incoming calls on it will not use up our POTS lines. I was even considering changing our third line to hunt to that VoIP line, so that when the 3 incoming voice lines are busy, it will use the VoIP line and basically give us a huge call capacity. I think we pay something like $5/mo for the VoIP number, plus 1.1c/min (CAD$). Normally DID's (direct inward dial, which is what numbers that terminate on VoIP are called) are cheaper than that, but this number is in an area not serviced by many VoIP providers.
A lot of providers will also provide some kind of failover if you're not connected, ie, they'll just forward the call to another number. Often this will cost double (cost of incoming call + cost of outgoing call) but it's definately better than customers not being able to reach you.
We've already noticed a decent savings on long distance costs. We were paying something like 4.5c/min on POTS, but now we can call anywhere in north america for 1.3c/min or somewhere in there.
The real benefit (and one of the main reasons we chose a voip system) will be when we setup our first branch office later this year, and calls between them cost nothing. One receptionist (you only get an IVR off-hours, or if the receptionist is busy) can handle calls for both offices, we can have local numbers in both cities that are treated identically, and staff are encouraged to communicate because calling someone in another city is identical to calling someone in the office down the hall.
There's also the possibility of working from home. You can actually take our desk phones home, plug them into an internet connection, and they'll work the same as in the office. You can also install a softphone on your PC/laptop, and have an extension. I'm looking forward to using that when I go to some conferences this summer.
Anyway, the possibilties are really endless, and there's no reason that "going VoIP" means ditching all your analog lines. I'd even say that combining them gives you the best solution.
Command line interface (CLI) is the way to go for real PBX systems. There is no GUI out there that really takes advantage of all the features of what Asterisk can do. And if you do need a gui to do something, chances are, you shouldn't be running your own PBX.
I guess it really depends on your skills and how much time you want to spend with the phone system. I personally prefer to work in GUI's for most things, as it saves me time from remembering obscure options and switches for hundreds of config files in different programs. Not to mention the additional error checking a GUI will provide, or the quick "summaries" they can give that pull information from various files together to give you an overall picture.
As far as no GUI that can take advantage of everything Asterisk can do -- that's pretty much like saying there's no GUI that can take advantage of everything Linux can do. Asterisk is incredibly flexible, which makes it very difficult to write GUI's. It's somewhat akin to writing a GUI for a programming language (since asterisk's dialplan is really a simple language). I'm one of the developers for AMP, and a common misconception is that AMP is a general GUI for editing any Asterisk setup, when in fact, it's a fairly specific configuration for Asterisk that includes a web GUI. It is really designed for use as a PBX in a small-to-medium sized business. People request things like support for calling cards, but it's just not designed for that kind of application. Of course, there's nothing stopping people from taking the GPL'd source and removing the extensions, IVR, etc stuff and making a configuration specifically to handle a calling card company.
Anyway, the point is you'll never get one GUI that takes care of "all" the features, because there's really an unlimited number of things you can do, and an unlimited number of ways to do them. That doesn't mean that a GUI is worthless. For a lot of situations, using something like AMP will save you lots of time, because you'll just be building the same thing by hand (reinventing the wheel, so to speak). Other times, you'll want a lot of custom stuff and a GUI tool like AMP won't be appropriate. Of course, you can use a mixture of things - AMP has many hooks for adding custom functionality, and there's nothing stopping people from writing additional functionality into the AMP GUI itself.
Why not just let linux handle the raiding of the drives? No special hardware needed ourside of the drive controllers you already need to hook the drives up.
Another point to this: there are three kinds of raid setups:
hardware raid - where the OS speaks RAID-specific commands to the controller
firmware raid - where software RAID is implemented in the firmware of the card
software raid - RAID done by the OS
From my reading on forums and other various articles, there's almost no (if any) benefit to using firmware-based raid over true software raid. In fact, it's possibly worse, as you're relying on the (possibly closed) software in the firmware of the card, as opposed to the well-tested and open implementation of mdadm (or whatever raid implementation you use). Chances are you'll also spend some time struggling with the driver and getting your kernel to recoginize it.
If you're going to go hardware raid, go for real hardware raid. Otherwise, I'd suggest sticking to mdadm and doing it in the OS. You get nice email alerts if there's a problem, and all the software will work so long as linux sees your IDE and SATA controllers (probably). You can even mix and match RAID across your IDE/SATA/SCSI/USB/1394 drives.
Jokes aside, one of my friends had a bucket of water poured onto his Dell laptop last summer (the result of a badly-aimed pratical joke). We thought it was totally screwed, so wiped it down and basically took everything that was semi-user-servicable out (battery, drive bays, pc cards, memory). After it sat for a few hours and dryed up, it was able to boot and has been working normally since.
It should be noted that it's not the water that kills devices, it's the water shorting out contacts that kills it. As long as you don't try to run it while it's on, it should survive. His was actually on when it happened, and turned off immediately, so I guess that part was just luck that it didn't fry anything.
You're not *there*. The developer isn't putting ads on his site, the developer is putting ads on your computer screen. More specifically, you tell your computer to send a request to a server for information. The server sends back information (often an html page) with references to other information: the advertisements and other images on the page.
There's ways to browse with those functions turned off. If you want to do that though, you're going to miss out on other content as well.
What is the issue anyways? I mean, it's one thing to have popup ads that are actually intrusive to the point where you can't do other things (like read an article), but ads embedded into a page? Ignore them if you don't want to see them. Hopefully at this point you can look at an ad without feeling the need to rush out and buy whatever's being advertised.
If you don't need or want to see the advertisements, why should you waste your own bandwidth sending more requests to the server and downloading ads?
Do you really expect to browse the internet and be frugal about bandwidth? If you're really concerned, you should just disconnect. Try running a port monitor, and see how many times other systems are trying to connect to your system and waste your bandwidth.
For business accounting on Linux there is Quasar, which is a "full function, stand-alone business accounting package." It has both a GPL and commercial licenses.
Which is probably great, if you're a new busines, and are running Linux.
For existing businesses, this poses many many problems (and I say this out of experience, being in the process of switching from SimplyAccounting and much paper-based stuff to a fully-computerized system based on QuickBooks and ESC). Let me tell you, this is an incredibly huge project. We're a fairly small company (15 people, I'm the IT department, among other things), and to be honest I don't know if it would be better or worse if we were bigger.
We have Windows desktops. Three biggest things holding us back: SimplyAccounting/Quickbooks, WordPerfect (though having played with OO.org 2 beta, it looks like we will finally be able to dump WP), and training.
To switch to Quasar, we'd have to install linux on at least all desktops using it. Somehow, we need to migrate everything from QB to Quasar (this does NOT happen overnight), so this would probably mean running dual desktops for acccounting people (which means spending more on hardware or vmware). At the same time, I have to deal with supporting another desktop platform, and people have to not only learn a new accounting system, but do it in a new, unfamiliar desktop environment.
We also somehow have to evaluate Quasar to be sure it'll even work for us, so there would have to be two systems for a while, which requires signifigantly more work than evaluating an accounting system that runs on our existing platform (install the software, decide if it works). Again, this means buying hardware or Vmware, and if we decide Quasar won't work, we've still spent this money.
Don't get me wrong here, I'd love to get rid of Windows. Our network has been running on OpenLDAP and Samba for over a year, and on other FOSS software like Apache and BIND9 for even longer than that (which greatly helped when we finally did switch to samba/linux). Over the last couple years, I've been concentrating on getting cross-platform or web-based software, but it's a slow process. Everyone here uses Thunderbird for email, and Firefox as a browser. All the custom apps I've written for us are web-based.
So switching to Quasar on linux? "Easier said than done". A good example of a reason cross-platform software is a good thing (I know there people who frown on making Windows ports because they thing it discourages people from moving to linux). If Quasar ran on Windows, it would at least be possible to evaluate it, and there would be a much better chance of using it. Eventually, once we were entirely running cross-platform applications, switching the actual OS wouldn't be a huge deal.
As it stands, we'll probably have to switch to Linux first (which we're a step closer to be able to doing with Crossover), then possibly switch to Quasar. I have to say though, since we only just went to QB, there would have to be a pretty huge incentive for me to switch away at this point.
I put in a number of black hole lists in my mail server config, and have found that with few exceptions, all ham mail is getting through, and the spam is getting disconnected without the relatively high resource cost of spam scanning (I got a really small mail server).
I personally don't like RBL's, and we've found that on our server they cause problems (we host about 200 domains). Inevitably, some ISP or system will get blocked, and it causes a problem for one of the domains. The RBL's are mostly irresponsible, and block too much.
A few days ago, we were blocked by SORBS (and couldn't send email to a local ISP). After trying to use their horrible website to find out why (it said we were listed until signing up for an account and logging in, then it said we weren't listed, despite still being blocked), we eventually found out that our entire subnet was blocked. We have about 16 IPs in this subnet, shared with other co-location customers at our provider. The reason the subnet was blocked? There was one system (not ours) that was apparently hacked and sending spam. By the time we notified our provider about the block, they had already found the offending system and disconnected it. I think we're still on SORBS, despite requests from both us and our provider to remove the entry.
We've also had our server specifically blocked because someone submitted a legitimate mailing list message as spam, rather than unsubscribing to the list. Based on that one message, our server was blocked for 24 hours.
I'm not sure why the RBL's do this sort of thing, because I think there's a growing mistrust with using them. It's a great idea, but they're making a mess of it.
I got a call last night that our mail server was really slow. Logged in to see that the load average is skyrocketing from spamd, and there are several thousand undelievered messages building up in the queue. We were in the process of getting a dictionary on a couple of domains, and spamassasin couldn't scan them as fast as they were coming in. I think last night it was about 400,000 messages.
Over the past few months, this has become more and more common, and now we're looking at putting another system in front of that for the sole purpose of scanning email. This costs us time figuring out how to deal with it (and dealing with it on a temporary basis to keep the server up), in the hardware we're going to have to buy, money to be spent to colocate another system, bandwidth costs, and the time to set it all up, and keep it running in the future.
How exactly do you figure there's no strain on the network admins?
Maybe you should move to Canada. It seems only the US has crappy connections.
At my old apartment, my $30/mo DSL account gave me 3mbps down and 800kbps up, with only port 25 blocked (a good thing.. I think all ISPs should do this).
My cable connection at home now is slower, but I think it's supposed to be about the same (I'll probably end up switching back to dsl).
At the office, we have a business cable package with 3 IP's (1 static, 2 that have never changed, though supposedly they could), 10 Mbps down and 1 mbps up. I regularly can download at 500kb/s. I've had 3 simultaneous downloads (on different IP's) going at 800 kb/s (yes, kilobytes) each. I believe this costs us $90CDN/mo.
I've had very good luck with the WD 8Mb cache range
Same here. It's all I've been buying for the last year or so. I have around a dozen in remote monitoring systems, 8 in servers in the office, and probably over half the systems in the office, plus I've used tons of them (not 8 meg) with other older systems (In fact, I just booted a 3gb WD the other day, still working). I've only had one WD go bad on me.
By contrast, I've had 4 or 5 Maxtors die, and I haven't used nearly as many.
I'd love to find a way to run just a single application over a link like this, instead of getting a whole desktop. That's much more integrated (or at least, would feel like it), and even WTS can't do it.
Slashdot Mirror
I thought that there were providers that would let you "hardcode" a location into their service -- ie, if you were using it at home, you put in your home address, and then that info is available to 911. If you're moving around, it's obviously going to be more difficult, but basically the same as a cell phone is now. At the least they know who you are.
I personally have settled on
.. and it doesn't take up lots of space, so that's ok.
PS1='[\u@\h:\w]\$ '
as my prompt. I work on many different systems (it's not uncommon for me to have 3 or 4 different sessions to different machines), so the hostname is almost a requirment. Username is a bit handy as well
I also started using \w as my path (which prints the full path) simply because it would be too easy to lose track without it. When you come back to a window and it says "[root@ws005:bin]# " that doesn't really tell you a lot. I much prefer to see "[root@ws005:/usr/bin]#" or "[greg@hydrogen:/usr/local/someprog/bin]$".
Also handy is that the prompt is a valid source/target for scp or rsync.
2) production code is not documentation on the APIs that it uses. APIs have their own documentation, the reader either is familiar with it, or can find documentation.
// 14 hours
I should have been more clear on this. I agree exactly with someone else that replied to this.. in this example, SDL_GetTicks() is not a clear name. If it was SDL_GetCurrentTicks() or something along those lines, fine. But since it's unclear, my "// now" hint is enough that I don't have to spend a few minutes looking for and searching through documentation or code to find a simple answer.
6) NEVER put actual values in comments. For example:
Normally I'd agree with this, but one thing I sometimes do is put translations.
update_interval = 50400;
This just saves me later wondering what "50400" is.
So your free music is DRMed to death? You're also gonna have to pay to put your "free" tunes on a DAP? Free as in beer locked in a safe I guess.
I wonder if some day a company will offer DRM-less music. I'd be willing to pay for that. When I get locked into using a crappy player, can't transfer music to another machine (such as my media jukebox running MPD that is controlled from a web browser and plays on my stereos), and possibly lose all access to it if the company goes under, I'm just not willing to pay for that "privledge".
There's also something as far as too much commenting. Don't get me wrong, I can't stand uncommented code. I learnt, like most people, the hard way -- go back to edit something I did 6 months ago, and have no idea what's happening.
But I don't think this is useful:
Here's my version of your same sectionThis isn't really the greatest example, but I like to comment sections of code. The details can be read by looking through the code, with "hints" as needed (for example, reminding me that SDL_GetTicks() is the current time).
Well commented blocks mean you can skim through the code, getting a quick overview of what's happening, without having to read in much detail.You don't have to care about the details of the look, you just know by the time you hit the } you've found what you wanted.
Don't take this personally or anything. Your code is very readable.. there's just lots of extra comments (granted, I've seen worse) that are really just not worth putting in.
(also, proper indenting is as, if not more, important.. of course,
Try harder, PSU provides email for 130,000+ users (generally around 6 million emails a day) without a RBL. RBLs are a bad solution looking for a problem, there are much better ways to deal with spam that are not run by clueless zealots.
.. but the reality is on a small scale it's not pratical to do. Adding just a 1U gateway doubles our colocation costs, means more admin work to keep them updated, and means spending more money on a system just to block spam.
Okay, let me add to that then. It's not pratical on our scale to run it without RBL's. We were getting at least one dictionary attack a day, and it was getting to the point where the system couldn't even keep up and we were getting several thousand messages waiting in the queue.
We were investigating adding another system to run as a mail server or gateway, upgrading our existing system, or offloading mail processing to another service. I'd love to have a dedicated mail server, or multiple systems load balanced
So it's OK to blacklist a little guy that has a misconfigured/hacked email server that is spitting out spam, but if a big fish does this, we should justify and make excuses for them??
.. blacklist them (whether they're AOL or a little isp). Of course, you should probably send a message to abuse@ their domain trying to inform them..
NO -- it's not ok to blacklist the little guy either.
If they're misconfigured/hacked, and spitting out spam, sure
Too many lists don't check though. They get a complaint, and bam, blacklist. I run a small web/mail server (300 domains, 16 IPs), and this is highly annoying. We've been blacklisted before because someone complained about a legitimate mailing list they were on. No double-checking, no investigation into the complain, we just got blacklisted immediately.
Most recently, we were blacklisted by SORBS because another system that shares colocation with our server was hacked. Immediately, they blacklisted the entire subnet. This affected us, and numerous other customers that have no affiliation other than sharing colocation space.
I noticed we were on the list when someone in the office complained about not being able to send mail to an address she could send to a couple hours earlier. Upon looking into it, we eventually found out that teh entire subnet was blocked (and we couldn't even request to remove the block), so we contacted our ISP. They told us they had just discovered that hacked system and disconnected it, and tried to get the block removed from SORBS.
In all, our ISP had found and disconnected the system within 3 hours of it being hacked, yet we were on the list at least 24 hours. During this time, none of our customers can send mail to anyone with a provider using SORBS. Our server was fine, their servers are fine, but because of a completely unrelated incident with unrelated people, it affects hundreds more.
The big problem is, it's basically impossible to run a mail server without using RBL's (we tried).. you just get hammered. RBLs are definately useful, but there are too many run by over-zealous admins with basically an itchy trigger finger. Hopefully stunts like this will make people realize the problems with RBLs and maybe we can drop the ones that are run this way.
I'm using AMP to manage everything. Everything I described in that post is fairly simple to do in the web GUI.
Programmers know too much about the inner workings of a system... and thus they will immediately think of all the reasons why an innovative idea (interface element or feature) won't work. But the naive user, not encumbered by such restrictive thinking, may propose powerful features and novel interaction schemes. Some of these won't work, and some really are too hard to code, but there are many gems.
.. just thinking about how the interface should act. Sometimes I'll even draw out an interface on paper first, or do a quick non-working prototype to get a feel for it. (Note, I'm refering to the usability, not necessarily the end look .. though these are related, I'm not concerned with colors, positioning, etc, at this point).
As a programmer, this is something I try really hard to do -- step back, and forget everything I know about the backend. When coming up with a new concept, I ask myself "What is the optimal way this GUI would be implemented?" without any regard for how things are structured behind the scenes
Once I have the "best" interface I can think of, I then start figuring out how to apply that to my backend structure. Sometimes this involves making comprimises and changing from my optimal interface, but usually it is doable. The big difference is now the problem is simply a matter of figuring out "how do i represent data x as y?" which is a specific task, as opposed to trying to figure out how to manipulate data AND display an interface at the same time.
It's just a different perspective to take, which is really the important thing.
unlimitel and livevoip.
The harder part was re-wiring my house so that all the phones would work using voip (instead of just having one phone plugged into the Linksys router). Even this is not too bad: just disconnect your internal wiring from the Telco, and then plug the voip router into a wall-jack, so that all wall-jacks are now connected to it.
:) )
Here's another idea: if you want your POTS line as well as a voip line, phones only use two wires (red and green). Yellow and black are spare, and are often used to run a second line. If you hook up your ATA to the yellow/black pair, then you now have both lines running everywhere in your house.* Get a two-line phone, and you can access both lines (this may require adding an additional jack wired to yellow/black), or selectively you can wire yellow/black instead of red/green to any jack to make it use the second line.
(*: This is assuming that all 4 wires have been connected anywhere they split in the house. Most newer homes have all the phone jacks with one continous wire coming down to a central location, where it's connected to the telco demarc, but the old method was to daisy-chain or just randomly splice into a nearby wire to add a jack. If this was done improperly, or worse, yellow/black red/green were interconnected somewhere, it can fry your equipment and be very hard to track down. Make sure you know what you're doing before you try anything like this. If you blow your phones/ATA/computer/self up, I take no responsibility
I can't tell you how many times I've had VOIP vendors approach me with their hair-brained notion of saving us money. The ridiculous per-line charge is where they start to fall on deaf ears with me. Our per-line cost with two PRIs is way lower than with VOIP. What, then if not cost savings, would inspire a change? Nothing that I can think of... some bells-n-whistles administration? Not going to offset the cost of equipment either since we own our phone stuff.
...). You get the best solution by taking the best each has to offer, using the best tool for the job.
Sounds like a case of sales people blindly suggesting a solution without knowing your needs. VoIP is not going to beat a T1, because really, what the VoIP providers do is get a T1 (or a few..) and sell services through them. A T1 really remains the most cost effective way to get PSTN connectivity (well, there are probably other bigger pipes that I don't know anything about, but these are only going to be cheaper per-line). For a small business with only a few lines, VoIP can definately save money -- provided it's implemented properly with some kind of redundancy/backup so your SLA-less DSL line going down doesn't mean you can't get calls from your customers.
In a larger business, VoIP can save quite a bit of money. I've talked to people who have T1 interconnects between offices just for internal lines. By switching to VoIP over their existing T1 or fiber-based internet service, they can eliminate the monthly costs of two T1 lines (one at each location), and typically the small investment in PC hardware running asterisk is easily paid back within a couple months.
Going VoIP doesn't mean you can't use other technologies (analog lines, T1's,
Is the on site documentation good enough or are there other resources you would recommend?
voip-info.org is like the bible of the VoIP/asterisk world. I definately recommend browsing around there before getting started, and keeping it bookmarked while you're installing and configuring asterisk.
I'm actually one of the developers for AMP, which is the web GUI that asterisk@home uses, and one of the biggest things I see is that there's a lot of people that want to just jump in thinking they don't need to know anything to get started. I'm not sure why this is, but you most definately need to understand basic concepts of a PBX, and some telephone technology, and how asterisk itself works in relation to those things. Most definately do not setup a mission-critical phone system (and I'd argue that any phone system used in a business instanly becomes mission-critical) without testing - a lot - first. Some people even setup test systems in their homes before hand.. and since the entry cost is so low, this is entirely possible. It's hard to recommend how much and what method to use for testing, since it varies depending on the size of your install. voip-info has some deployment tips though, that are probably very useful.
After taking this into consideration, unfortunately, going through the local Ma Bell monopoly was still the cheapest and most reliable option for us (a business needing 3-5 phone lines).
Usually there are resellers that will get you a fully-featured POTS line at well below the cost of a line from Ma Bell. Bell Canada is the main carrier here, and I can get lines from either AllStream or Primus for several dollars less than Bell, and they include many features -- call/name id, hunt group, other stuff I don't use -- at less than the cost of a basic line from Bell.
We've been running on Asterisk for a couple of months now, and it's made an impact on our phone bills. Our telephone hardware was aging anyways, so we deployed Asterisk with all new (and low-cost) VoIP phones, at around the same price it would have cost to get a low-end, not very configurable non-VoIP system.
We have 4 incoming analog POTS (plain old telephone service) lines (one is dedicated to fax). We have two VoIP providers (mostly just for redundancy.. outgoing minutes are cheap). Long distance calls are routed through VoIP, and a maximum of two local calls will get routed through POTS lines before using Voip, which for the most part keeps a POTS line free for incoming calls. If our internet is down, long-distance calls simply fail over to the POTS lines, and if they're all used up it tells you "all lines are busy now", which is annoying but not any different than it would be without VoIP.
Since we just moved and were forced to change our number, I'm waiting on getting our old number switched to a VoIP provider. Right now it's call-forwarded to our new number, but when it goes VoIP, incoming calls on it will not use up our POTS lines. I was even considering changing our third line to hunt to that VoIP line, so that when the 3 incoming voice lines are busy, it will use the VoIP line and basically give us a huge call capacity. I think we pay something like $5/mo for the VoIP number, plus 1.1c/min (CAD$). Normally DID's (direct inward dial, which is what numbers that terminate on VoIP are called) are cheaper than that, but this number is in an area not serviced by many VoIP providers.
A lot of providers will also provide some kind of failover if you're not connected, ie, they'll just forward the call to another number. Often this will cost double (cost of incoming call + cost of outgoing call) but it's definately better than customers not being able to reach you.
We've already noticed a decent savings on long distance costs. We were paying something like 4.5c/min on POTS, but now we can call anywhere in north america for 1.3c/min or somewhere in there.
The real benefit (and one of the main reasons we chose a voip system) will be when we setup our first branch office later this year, and calls between them cost nothing. One receptionist (you only get an IVR off-hours, or if the receptionist is busy) can handle calls for both offices, we can have local numbers in both cities that are treated identically, and staff are encouraged to communicate because calling someone in another city is identical to calling someone in the office down the hall.
There's also the possibility of working from home. You can actually take our desk phones home, plug them into an internet connection, and they'll work the same as in the office. You can also install a softphone on your PC/laptop, and have an extension. I'm looking forward to using that when I go to some conferences this summer.
Anyway, the possibilties are really endless, and there's no reason that "going VoIP" means ditching all your analog lines. I'd even say that combining them gives you the best solution.
Command line interface (CLI) is the way to go for real PBX systems. There is no GUI out there that really takes advantage of all the features of what Asterisk can do. And if you do need a gui to do something, chances are, you shouldn't be running your own PBX.
I guess it really depends on your skills and how much time you want to spend with the phone system. I personally prefer to work in GUI's for most things, as it saves me time from remembering obscure options and switches for hundreds of config files in different programs. Not to mention the additional error checking a GUI will provide, or the quick "summaries" they can give that pull information from various files together to give you an overall picture.
As far as no GUI that can take advantage of everything Asterisk can do -- that's pretty much like saying there's no GUI that can take advantage of everything Linux can do. Asterisk is incredibly flexible, which makes it very difficult to write GUI's. It's somewhat akin to writing a GUI for a programming language (since asterisk's dialplan is really a simple language). I'm one of the developers for AMP, and a common misconception is that AMP is a general GUI for editing any Asterisk setup, when in fact, it's a fairly specific configuration for Asterisk that includes a web GUI. It is really designed for use as a PBX in a small-to-medium sized business. People request things like support for calling cards, but it's just not designed for that kind of application. Of course, there's nothing stopping people from taking the GPL'd source and removing the extensions, IVR, etc stuff and making a configuration specifically to handle a calling card company.
Anyway, the point is you'll never get one GUI that takes care of "all" the features, because there's really an unlimited number of things you can do, and an unlimited number of ways to do them. That doesn't mean that a GUI is worthless. For a lot of situations, using something like AMP will save you lots of time, because you'll just be building the same thing by hand (reinventing the wheel, so to speak). Other times, you'll want a lot of custom stuff and a GUI tool like AMP won't be appropriate. Of course, you can use a mixture of things - AMP has many hooks for adding custom functionality, and there's nothing stopping people from writing additional functionality into the AMP GUI itself.
Another point to this: there are three kinds of raid setups:
- hardware raid - where the OS speaks RAID-specific commands to the controller
- firmware raid - where software RAID is implemented in the firmware of the card
- software raid - RAID done by the OS
From my reading on forums and other various articles, there's almost no (if any) benefit to using firmware-based raid over true software raid. In fact, it's possibly worse, as you're relying on the (possibly closed) software in the firmware of the card, as opposed to the well-tested and open implementation of mdadm (or whatever raid implementation you use). Chances are you'll also spend some time struggling with the driver and getting your kernel to recoginize it.If you're going to go hardware raid, go for real hardware raid. Otherwise, I'd suggest sticking to mdadm and doing it in the OS. You get nice email alerts if there's a problem, and all the software will work so long as linux sees your IDE and SATA controllers (probably). You can even mix and match RAID across your IDE/SATA/SCSI/USB/1394 drives.
Jokes aside, one of my friends had a bucket of water poured onto his Dell laptop last summer (the result of a badly-aimed pratical joke). We thought it was totally screwed, so wiped it down and basically took everything that was semi-user-servicable out (battery, drive bays, pc cards, memory). After it sat for a few hours and dryed up, it was able to boot and has been working normally since.
It should be noted that it's not the water that kills devices, it's the water shorting out contacts that kills it. As long as you don't try to run it while it's on, it should survive. His was actually on when it happened, and turned off immediately, so I guess that part was just luck that it didn't fry anything.
Wifi handhelds are around the corner
or here.
You're not *there*. The developer isn't putting ads on his site, the developer is putting ads on your computer screen. More specifically, you tell your computer to send a request to a server for information. The server sends back information (often an html page) with references to other information: the advertisements and other images on the page.
There's ways to browse with those functions turned off. If you want to do that though, you're going to miss out on other content as well.
What is the issue anyways? I mean, it's one thing to have popup ads that are actually intrusive to the point where you can't do other things (like read an article), but ads embedded into a page? Ignore them if you don't want to see them. Hopefully at this point you can look at an ad without feeling the need to rush out and buy whatever's being advertised.
If you don't need or want to see the advertisements, why should you waste your own bandwidth sending more requests to the server and downloading ads?
Do you really expect to browse the internet and be frugal about bandwidth? If you're really concerned, you should just disconnect. Try running a port monitor, and see how many times other systems are trying to connect to your system and waste your bandwidth.
For business accounting on Linux there is Quasar, which is a "full function, stand-alone business accounting package." It has both a GPL and commercial licenses.
Which is probably great, if you're a new busines, and are running Linux.
For existing businesses, this poses many many problems (and I say this out of experience, being in the process of switching from SimplyAccounting and much paper-based stuff to a fully-computerized system based on QuickBooks and ESC). Let me tell you, this is an incredibly huge project. We're a fairly small company (15 people, I'm the IT department, among other things), and to be honest I don't know if it would be better or worse if we were bigger.
We have Windows desktops. Three biggest things holding us back: SimplyAccounting/Quickbooks, WordPerfect (though having played with OO.org 2 beta, it looks like we will finally be able to dump WP), and training.
To switch to Quasar, we'd have to install linux on at least all desktops using it. Somehow, we need to migrate everything from QB to Quasar (this does NOT happen overnight), so this would probably mean running dual desktops for acccounting people (which means spending more on hardware or vmware). At the same time, I have to deal with supporting another desktop platform, and people have to not only learn a new accounting system, but do it in a new, unfamiliar desktop environment.
We also somehow have to evaluate Quasar to be sure it'll even work for us, so there would have to be two systems for a while, which requires signifigantly more work than evaluating an accounting system that runs on our existing platform (install the software, decide if it works). Again, this means buying hardware or Vmware, and if we decide Quasar won't work, we've still spent this money.
Don't get me wrong here, I'd love to get rid of Windows. Our network has been running on OpenLDAP and Samba for over a year, and on other FOSS software like Apache and BIND9 for even longer than that (which greatly helped when we finally did switch to samba/linux). Over the last couple years, I've been concentrating on getting cross-platform or web-based software, but it's a slow process. Everyone here uses Thunderbird for email, and Firefox as a browser. All the custom apps I've written for us are web-based.
So switching to Quasar on linux? "Easier said than done". A good example of a reason cross-platform software is a good thing (I know there people who frown on making Windows ports because they thing it discourages people from moving to linux). If Quasar ran on Windows, it would at least be possible to evaluate it, and there would be a much better chance of using it. Eventually, once we were entirely running cross-platform applications, switching the actual OS wouldn't be a huge deal.
As it stands, we'll probably have to switch to Linux first (which we're a step closer to be able to doing with Crossover), then possibly switch to Quasar. I have to say though, since we only just went to QB, there would have to be a pretty huge incentive for me to switch away at this point.
I put in a number of black hole lists in my mail server config, and have found that with few exceptions, all ham mail is getting through, and the spam is getting disconnected without the relatively high resource cost of spam scanning (I got a really small mail server).
I personally don't like RBL's, and we've found that on our server they cause problems (we host about 200 domains). Inevitably, some ISP or system will get blocked, and it causes a problem for one of the domains. The RBL's are mostly irresponsible, and block too much.
A few days ago, we were blocked by SORBS (and couldn't send email to a local ISP). After trying to use their horrible website to find out why (it said we were listed until signing up for an account and logging in, then it said we weren't listed, despite still being blocked), we eventually found out that our entire subnet was blocked. We have about 16 IPs in this subnet, shared with other co-location customers at our provider. The reason the subnet was blocked? There was one system (not ours) that was apparently hacked and sending spam. By the time we notified our provider about the block, they had already found the offending system and disconnected it. I think we're still on SORBS, despite requests from both us and our provider to remove the entry.
We've also had our server specifically blocked because someone submitted a legitimate mailing list message as spam, rather than unsubscribing to the list. Based on that one message, our server was blocked for 24 hours.
I'm not sure why the RBL's do this sort of thing, because I think there's a growing mistrust with using them. It's a great idea, but they're making a mess of it.
It doesn't put any strain on network admins.
Did you even read his message at all?
I got a call last night that our mail server was really slow. Logged in to see that the load average is skyrocketing from spamd, and there are several thousand undelievered messages building up in the queue. We were in the process of getting a dictionary on a couple of domains, and spamassasin couldn't scan them as fast as they were coming in. I think last night it was about 400,000 messages.
Over the past few months, this has become more and more common, and now we're looking at putting another system in front of that for the sole purpose of scanning email. This costs us time figuring out how to deal with it (and dealing with it on a temporary basis to keep the server up), in the hardware we're going to have to buy, money to be spent to colocate another system, bandwidth costs, and the time to set it all up, and keep it running in the future.
How exactly do you figure there's no strain on the network admins?
Maybe you should move to Canada. It seems only the US has crappy connections.
At my old apartment, my $30/mo DSL account gave me 3mbps down and 800kbps up, with only port 25 blocked (a good thing.. I think all ISPs should do this).
My cable connection at home now is slower, but I think it's supposed to be about the same (I'll probably end up switching back to dsl).
At the office, we have a business cable package with 3 IP's (1 static, 2 that have never changed, though supposedly they could), 10 Mbps down and 1 mbps up. I regularly can download at 500kb/s. I've had 3 simultaneous downloads (on different IP's) going at 800 kb/s (yes, kilobytes) each. I believe this costs us $90CDN/mo.
I've had very good luck with the WD 8Mb cache range
Same here. It's all I've been buying for the last year or so. I have around a dozen in remote monitoring systems, 8 in servers in the office, and probably over half the systems in the office, plus I've used tons of them (not 8 meg) with other older systems (In fact, I just booted a 3gb WD the other day, still working). I've only had one WD go bad on me.
By contrast, I've had 4 or 5 Maxtors die, and I haven't used nearly as many.
I'd love to find a way to run just a single application over a link like this, instead of getting a whole desktop. That's much more integrated (or at least, would feel like it), and even WTS can't do it.