Straight out of university, I recommend going out and landing that job. Get some work experience for at least a few years, have some fun, and see what you like in the Real World version of the field.
With luck, you'll run into something that's a problem for your employer, and potentially a thesis topic worth pursuing professionally.
With more luck, you'll be in an environment that lets you work on your masters part time (3yrs in my case) while collecting a full time paycheck. Very handy that paycheck - I could not have done this on much less than full pay.
With more more more luck, your employer might even pay tuition for you.
With more more more more more more more luck, you'll actually enjoy both your work and your area of focus.
I've been lucky.
Note: part time study & full time work cuts down on fun big time, and makes friends nag you for not attending all social events. Avoid losing friends and your sanity by taking time out, even if it means cramming a few days later.
Not done much work with NFS then, I take it ? Or services that have long timeout periods and don't die nicely ?
Amen. Hoping for a long, stable uptime on a linux machine that does very intensive and sustained NFS I/O provde to be pipe dream for me. Things did get much better after applying the plethora of nfs.org patches, but you still get some awesome kernel failures.
But I don't care, because I have many machines accessing the NFS mount (mailboxes, btw). I lose one, and keep on ticking. If I lose one machine every 3-4 months for an hour, my service availability stays good - though maybe a bit slow depending on the time of day. I could have mounted the shares on a set of Solaris boxes, but the cost for knowledgeable staff would have been far greater than sticking with Linux. That's right, hardware & software are generally much cheaper than the people to manage it.
So I agree that the original poster's "13+ years" experience with Linux is either a troll, or someone that doesn't have anything but simple use cases for his champion OS.
Individual components of a computing infrastructure will fail. I don't care if it's a $500 compute node, or a $20M disk array. You have to assume that this failure will occur in your design. Availability comes from design with this intent, and that sort of design is expensive.
It always comes down to dollars! As a business, you generally permit the expenditure on highly available design when it has a strong business case. Will you lose $1mil in revenue because of a string of outages? If the probability is very high that the answer is yes, then it would be reasonable to secure $300-400k to remedy the situation. If the highly availabe design costs you $300-400k, but the expected losses from your flaky infrastructure are $50-100k, the money will not be spent, regardless of how many times you whinge on Slashdot.
And so, we accept these average performing, generally there services because we consider it good value for the dollars we pay. We complain that it should be better - sure - but we don't change providers because of the dollars involved.
This is for windows operating systems only. The name may sound ungainly, but the software (particularly the recent v3.1 refresh) works really well for this sort of use case. Pricing is approximately $50/license, available in 25-packs direct from IBM, or in smaller increments from a reseller. Very good value for money, and I say this as a satisfied customer.
Backs up to network drives, WebDAV folders, or tivoli storage manager servers. The first two will be applicable to small businesses.
The software monitors the I/O drivers, and just copies changed blocks once an initial synch has been done. This ensures that only the changed data is pushed over what can be a preciously network link.
It can also simultaneously keep a copy of the protected data in another folder/directory, allowing for immediate restore should a file get corrupted. Very handy stuff.
The most challenging element with the setup then becomes getting a quiesced copy of the database files. This can probably be acheived by having the administrators write a small script to stop MSSQL, run a manual backup, then restart MSSQL. A bit annoying, but backing up MSSQL live is normally the realm of far more expensive software.
Wrong: A good RBL is worth its weight in gold.
on
Choosing a Good DNSBL
·
· Score: 1
I would suggest that you are uninformed, and do not run a high volume mail system.
I'm responsible for a mid-sized mail system that receives an average of 10,000,000 connection requests per day. A good RBL is worth a lot to my employer.
We use Spamhaus xbl-sbl, and Trend Micro's Network Reputation Service - which is a combination of the more static RBL+ (of MAPS fame) and the highly dynamic QIL list.
Together, they drop approximately 92% of inbound connections to the SMTP server farm. This is a lot cheaper, computationally and financially, than using the lists later on in a content filtering stage. Without these RBLs, we would require ten times the CPU power to move and filter the messages that the dropped connections would undoubtedly attempt to deliver.
The RBLs allow us to provide customers with good to excellent filtering, at a tenth of the infrastructure cost that would be required without them, subscription cost to the two lists included. When we use a standard server build that runs approximately $15k/system, plus another $10k/system to rack, power, and cool it over it's lifetime (~3yrs) that's almost $450k saved over 3 years! And I'm not counting the bandwidth saved here, which is a substantial savings when buying international transit in Australia.
But the best part about the whole thing is the recorded number of complaints. I'm up to 10 in the past year. Even if the reported to unported ratio is 100:1, that's pretty excellent given the size of our customer base, and it's makeup - a lot of businesses that will complain if mail is blocked. Most problems were due to the QIL being a bit trigger-happy with listing other major Australian ISPs. No worries - it can be configured to whitelist by country, ISP, and arbitrary IP ranges. Fantastic.
Only a couple of complaints from people running mail servers behind DSL, in a residential (marked as dynamic) range. To these people I have one message: pay up to get a static (aka. business) grade service, co-locate your mail server, or get a real provider to be your mail host. Most spam comes from zombies sitting behind dynamic IP blocks - this is why they get dropped.
The final nicety from subscribing to these lists is while their support is good if you're a non-customer trying to be delisted (6-12hrs, tested prior to subscribing), their support is excellent when you're a customer. Quick to get spam evidence, quick to fix problematic listings of our systems _if the work has been done to clear the source_!
In summary: 1. spam still gets through the system. Now seeing 3-4% of connection attempts resulting in a delivery to a customer mailbox. Without the two RBLs on the front end, much more spam is seen because content filters are far from perfect. 2. Contrary to your assertion, list sharing is quite low: about 50% of the addresses are common between the two lists. In other words, we get about 60% connections dropped per list, for an aggregate of that 92% figure. If you assume that some spam sources are prolific, it indicates quite a bit of novel collection on the part of each. 3. A well run list isn't run by a schmuck. It's run by a company, with customers who pay it to do a good job and err towards reducing false positives. If you want schmuck, use SORBS.
I run a high volume mailserver, this is a bad idea
on
Fight Spam With Nolisting
·
· Score: 4, Interesting
I run a mail system that pushes ~3million messages per day. Not huge, not small.
We have thousands of domains pointed to our mail servers and secondary MX servers. Looking at the long run stats, I'd be tempted to completely disregard this technique.
When we take a primary down for maintenance, the secondaries and alternate primaries (same weight MX) see the load almost immediately.
I second the opinion that if this has any effect, it's only for low volume applications, with few/one domain.
We generally see more hits straight to the secondaries by spammers hoping for less rigorous checking. It would be interesting to profile IPs connecting to secondaries without being seen at the primary assuming a primary is always available - I bet that a very high percentage of these connections to secondaries could be viewed as spam.
The problem remains that most tricks of this sort - including greylisting - are eventually circumvented by spammers once the trick gains critical mass. Lets not forget that there are a lot of broken, yet not open relay, mail servers out there. Good engineers and administrators quickly find that Jon Postel's words ring true with their customers "Be liberal in what you accept, and conservative in what you send." - don't let your RFC enforcing configuration be responsible for delaying/blocking the delivery of that big contract your PHB was waiting for!
I have a love/hate relationship with Berkeley DB. This comment applies to OpenLDAP.
It's moody (DB_CONFIG anyone?), it's fast, gets reliable somewhere after many minor releases (started to trust 4.2.52, 4.3.25,...), and if it gets corrupted, you'd better have a backup.
I agree with your point, in theory - RDBMS datastores could offer a lot of flexibility, and eliminate many data redundancy complications. In small-ish implementations, you may be fine.
The implementations I've seen are a different animal.
1. Berkeley DB is fast. When you're issuing a lot of reads(3000+/sec/replica), across what is already a large farm (20+) of replicas, BDB means less hardware, hence far less cost than any RDBMS datastore. 2. RDBMS backends for OpenLDAP aren't as well tested. This matters when your database drives your email, authentication, authorization, and address books.
But I agree that the RDBMS should be the _authoritative_ data store. It should populate your LDAP directory. Yes, that's easier said than done. The benefits of this are great though - flexible lower throughput data for the applications that can use it, low data redundancy ( if you've designed both your RDBMS and LDAP schemas properly), blazing read speeds, and excellent service availability.
I completely agree with you, and am completely baffled by the article's ascertations.
I work for a Melbourne ISP, and can assure you that finding skilled operations and development (two different roles there!) people is difficult. Our salaries are above average, the work varied, yet we still generally find a glut of skilled people.
And to answer those suggesting that we employ junior personel and train them up -we do. Though you can't expect to succeed as a company with one or two senior people and an army of juniors.
Though I can't say that this is a problem just in the IT industry. Australia's immigration laws are almost draconian, and their quotas are too low. Really. I've had chats with people in the engineering, legal, and architectural fields - all are looking for more experienced staff to balance their junior ranks, and are willing to pay for it.
Come on Australia, help your booming economy - increase the skilled migrant quota, and drop the required score!
The article was discussing the Open Power systems, i.e. OpenPower 710, 720. Quoth the IBM literature, they have been optimized for linux, and ship with Linux only. Running AIX and OS400 on them is not supported, and probably prohibited by some evil trinket:)
The POWER chip is a different story, and yes, is availble in other lines of IBM servers that do run a wider range of OSes.
Virtualization is your friend, but don't get the sales people started...
You can buy power from... IBM. And it's not cheap. And it doesn't run AIX, only Linux. Sort of. Many applications require some porting love, as per the bounties on http://www.linuxonpower.com/
I generally like what IBM does, and use their x86 servers, storage, and software.
But "Open" is pushing it here.
I'd never be able to justify a recommendation to buy Open Power, that is, unless the sales guy left a flashy car in my parking spot...
Jonathan Schwartz (Sun CTO) had it right when he noted that that was as silly as them shipping Open Sparc boxes. Mind you, there are Fujitsu SPARC64 chips, and OEM sparc-based system builders.
Of course, IBM is just loving Solaris, particularly Solaris 10. Some assistance in your Solaris to Linux on Power migration? http://www-128.ibm.com/developerworks/linux/librar y/l-pow-portsolaris/ (Though it is a well written piece - good quick guide to Linux and Solaris system calls, signals.)
You seem to be confusing the market that this thing is targetted as. This is Storage Area Networking, normally applied to systems for who's downtime cost far more to the company than this disk.
First, it's fast disk. Fibre Channel drives, using 15 000 rpm (up to 146GB now?), or 10 000rpm (300GB) disks.
Second, it's expandable. Just add extra drive chassies on the expansion loops.
Third, and the reason people buy these, is that it makes managing storage for 10s to 1000s (DS8000) of machines simpler. Only allocate the amount you need, but grow it easily without the hassle of dealing with normally under utilized scsi system disks.
This equipment is for "big time", highly reliable, yet highly redundant computing. That costs money. Your suggestion is for cheap cheap disk - and you should be looking at someone like www.infortrend.com if you had a $5k budget and wanted SATA-to-SCSI. The dual AMD and 4GB ram is a waste in your config.
...but consider stuff like GCJ, Kaffe, Pizza, etc. The Java community has survived them;
Sure, because in production environments, Sun's JVM drives the code.
Sun has to be careful about the open sourcing of Java. The language could use the innovation and backing that an open license could provide, yet the last thing any user or developer needs is for code that looks like Java to require a specific (non-Sun) virtual machine to run properly.
There is no need for packages like those in Debian stable who require 'kaffe' and not 'java-virtual-machine'.
Given your environment's description, it would seem like moving to Debian would be a good choice.
1) You have no existing support contracts to honour 2) you're running an OS which no longer has vendor/distro supplied patches. There is the fedora legacy project, but I'm unsure of it's status. 3) It's a lot less hassle to run one version of one distro, than multiple versions of one distro (i.e. RH 7.x/8/9). 4) You can put custom packages or backports in a private repository for those machines that really do need them.
Like all decisions of the sorts, ensure that it's good for the business, and that you have the support of your peers.
I spent several months looking at a sole successor for our set of 150 linux (mostly Debian, some RH), Solaris, and Windows systems. We had been running backups with a hard to manage mash of rsync's, Amanda, Legato Networker, and Veritas Netbackup.
At the end of the day, Tivoli Storage Manager bested out Veritas NetBackup. In testing, I knew that I could run the tivoli code under Debian. But when you're considering a mass Debian deployment of code designed for RedHat/SuSe, you drop any thoughts of using Alien other than for quick tests. You have to find an IBM support team that will work with you should you run into trouble with a non-supported distribution such a Debian, but you also have to realize that at the end of the day, they will run on best effort because they have not tested their code on Debian.
So far, things are working well with Debian/stable systems. There was a bug in the initscripts package that caused a bit of heck on the very few Debian/testing systems that I was running, but it was overcome with 30 minutes worth of work.
Still, the bottom line is to do what's best for your business, not what's best for you. We chose Debian because it's very stable, and relatively easy to support. The only problem with it is explaining to vendors why we don't use RedHat Enterprise or SuSe Enterprise (namely, dollars). The IBM people are very comfortable with SuSe and RedHat - which means your troubles will be resolved quickly. You will find some very intelligent IBM people that will help you out with non-standards such as Debian, but you will pay for it in time-to-restoration if you aren't fully on the ball.
For most companies, software is a tool which supports the generation of revenue. Zero cost software is of no use to them if downtime/support wastes more money than commercial software, subscriptions (RH/SuSe), or support contracts would.
In your case, it seems that you're currently running an enviroment that IBM fully supports, and is supported by your linux distributor/vendor. Don't be dumb, stick to what you've got.
You could "upgrade" a reiser3 FS to a reiser4 FS if the partition was software raid-1.
I've done ext2 -> reiser3, and ext2->XFS with this before on production servers.
See the software RAID howto for specifics, but:
1) unmount, stop and split the mirror 2) mkfs.reiserfs4 one half of the mirror 3) mount the new and old halves of the mirror, and copy data from the old half to the new half [ cd/olddir; find . -xdev | cpio -pdmu/newdir ] 4) rebuild the mirror using the new half as a source, attaching the old half once created.
Of course, it's probably less work to just back the disk up and blast it. Although it could save you time wirh boot disks, and unmountable partitions. Heck, you wouldn't do this without a backup anyways, right?
Whoa. You're comparing RIAA tactics to non-free (as in _libre_ and dollars) software vendors.
Your comparison is totally inappropriate.
With per-cpu licensing, the assumption is that the software can do more for you on a multi-cpu system, hence you pay more for it. There's nothing terribly dodgy about this.
After all, whey you're paying for performance, the vendor (and buyer) wants to find a useful billing metric that's easy for everyone to understand. Anyone who's dealt with Veritas's 20 or so tiers will appreciate this.
Per cpu is the way to go then. The customer maximizes their investment when running on the fastest CPUs available, which isn't normally a big deal when the cost of the software far exceeds the cost of 3.2GHz Xeons or equivalent Athlons.
Per-cpu also solves the issue of pricing a single-cpu x86 (little $), versus a 32+ cpu sparc box (big $), versus 32x single-cpu x86 clusters.
So, when multiple-core chips come out, they'll essentially be multi-cpu. easy. Use them, pay more.
Because of competition from free ($/libre) software, licensing arrangements have gotten a lot more sane in the past couple years. Vendors are trying to stay away from that line in the sand where it becomes cheaper to re-train,re-build,re-deploy than to re-license.
This is very much unlike the RIAA,MPAA, and their friends in other countries who see it fit to take a much more extortive stance. Remember that most vendors let you move a per-cpu license around to different OSes and architectures, something that surely can't be said of the entertainment industry (oh, you own this on videocasette? You can have the DVD for media & packaging costs, or just download the content from http://videos.com)
Let's not forget that the freedom in documentation that you want is more than many, including myself, would consider appropriate.
To be 100% DFSG-defined free, some have argued in debian-devel and debian-legal you should be able to edit, and redistribute your edits of any documentation.
Sounds ok when you first think of it, which is probably why the general resolution that proposed that changed passed. But then you realize that:
1) the docs include standards, like RFCs, which _should not_ be changed and redistributed, less confusion ensue. There is a formal process for contribution and review, but just editing the docs isn't it.
2) the docs include license texts, like the GPL, APL, etc. The condition of using and redistributing most of the code in debian/main, including such useful things as the kernel, glibc, gcc, g, is that the text of GPL be distributed along with it. However, the GPL text itself isn't 100% free from the DFSG's point of view because it once again cannot be altered and redistributed as the GPL. And bingo, you're stuck! The GPL can't be put into non-free, because is presence is mandatory, but good luck in having the FSF alter their license.
I have nothing against a free _software_ interpretation of the DFSG, but there are good practical reasons why the same freedoms cannot be applied to the documentation.
----------seperate point for discussion----------- Interesting thing - wait much more than 6-12 months for Sarge, and most serious debian installs will be running production systems with a heavy concentration of backports.
And with backports, there are less eyes on the package's code level, and less eyes to notice that an update may have been released to plug some security problems. But there's the trap: (1) use testing and have a too volatile OS, (2) use stable + backports and get a functional os, that's generally secure, or (3) use just stable and get an OS that in time loses the ability to deliver 'standard' features, i.e. functions that have been available for more than a year.
I love Debian as a distribution. As with all things decided in a democratic fashion, it will never be everything to everyone - not even those hoping for '100%' libre.
Nevertheless, there's a few things that I wish the project would relax on a bit, w.r.t the DFSG.
-licensing. APL and MPL licensed software is potentially heading towards non-free. Why? Because of the clause to the licenses that states that you abandon all patent claims when contributing code. To me, this is fantastic, and stops companies from contributing code, then making turning about-face and suing everyone that uses it once a patent for a mechanism used therein is granted a patent. I view these licenses as "more-free" but there is much disagreement. We may not like software patents, but ignoring their existence is no way to handle the issue.
-the dissident test. This terribly frustrating test causes problems with modifying code and documentation for many packages, in the hope of ensuring that any moral dissident does not have to be bound to exposing their identities if they alter/contribute code. It's a funny thing, because dissidents normally operate outside the boundaries of their region's laws, purportedly to eventually have these altered. Why accomodate people who, by definition, will ignore your rules when they see it fit?
Anyways, I'm glad for this vote, as it means that we can get an updated stable soon-ish, something that is long overdue.
Your problem is entirely with Debian's approach to Java.
I develop and assist in maintaining over 100 Debian systems at work. The debian packaging tools are fantastic. Tack on a few small scripts, and you could expend very little effort on maintaing hundreds of machines.
Until you get into Java, which just about every enterprise is. If you're serious about it, you drop almost everything that the Debian project does w.r.t java, and add the following to your sources.list file:
deb http://z42.de debian/ deb-src http://z42.de debian/
Get j2se-package, which nicely builds sun-j2sdk1.x and sun-j2re1.x packages out of the Java.bin files that you get from java.sun.com.
You then throw these packaged into your in-house repository. Redistribution of a modified JRE or SDK (like a Debian package) is prohibited by Sun's current licensing terms.
You then might want to rebuild any Debian java packages for your repository using Sun's Java, and not Kaffe or any other hacks. When developer's complain that certain classes aren't working, answering 'but there isn't a DFSG compliant jvm that will support them' is generally not the way to promote harmony at the office, or to guard your job security. RMS disagrees with this, as per his article on 'The Java Trap', but I work in a world of reasonable compromise.
Of course, being a serious enterprise user of Debian, your in-house repository will contain a heck of a lot more packages that Java. Probably because you're running Debian/stable, with a volley of backports to support more recent versions of certain packages. OpenLDAP 2.1, MailScanner, SpamAssassin, and Apache2 come to mind.
I love Debian, I just hope that the bickering over the latest version of the DFSG doesn't draw developers away, or critically delay the release of Sarge.
Did you know that the new DFSG _should_ require many standard packages exit the main distribution and enter non-free? We're talking anything MPL'ed, APL'ed, potentially reiserfs(*), and if a few posters on debian-legal and debian-devel were to be believed, even GPL'ed code (the pre-amble).
(*)Because of the mkfs.reiserfs advertisement - you get an amazing filesystem for _nothing_, yet you complain because the funding agencies are shown while mkfs is running? Get real.)
It will apparently take another month or so to finalize the weighting of the rules.
I've put 3.0.0pre1 on a production system that filters ~350k messages per day. With some tweaking of the RBL, bayes, and AWL rules, it is much (~10%) more efficient at tagging spam than 2.63, which I'm running on a parallel server that also sees ~350k messages/day (load balancing is your friend).
Imagine being somewhere where there'd be no want to make firearm ownership a right.
That's where the arguments for ownership fall appart.
That's where the worst thing the media can report on is a bunch of kids attacking one another with knives and fists, never really being a problem to the bystander 100m across the park.
That place is anywhere where there is no right and hence no supply to meet the demands of irrationality. You would make a fine candidate for working anywhere, save a warzone.
An armed citizen can lose his or her cool and do everlasting damage. An unarmed one can have everlasting impact.
My major torment in Melbourne is not being able to get a consistently fantastic cup of drip coffee.
An extra large cup of the fresh stuff used to cost me $1.50 cnd, for half a liter of caffeinated goodness.
Now, a 'large' (250ml) flat white or long black sets me back $3.00au. ($1cnd ~= $1au at the moment).
The only Drip coffee alternative is Starbucks, which doesn't bother with non-espresso based coffees until 10am. The horror.
Back to the topic at hand, in reasons to re-locate: America: 2 weeks vacation if you're lucky. Low tax. Canada: 3 weeks vacation rather standard. Higher tax. Australia: 4 weeks vacation guaranteed. Tax higher than CND, but on it's way to dropping to equivalent rates.
But hey, I could care less about taxes. Give me education and healthcare that works, cities that are clean, an approach with firearms that doesn't make ownership a right, and I'll happily shell out between 30-40%.
True, both the Canadian and Australian laws haven't been tested as per my first comment, but the impact of breaking the Canadian one has far less repercussions should a judgement be issued against the users of material covered by the Act.
Now that I live in Melbourne, it frustrates me that I can't legitimately backup the music that I buy, or convert its format to something more suitable for my mp3 player.
That citizens (generally) blazenly ignore this law is a different issue - the point is that they shouldn't have to.
Slashdot Mirror
context: I'm 1 month away from my masters.
Straight out of university, I recommend going out and landing that job. Get some work experience for at least a few years, have some fun, and see what you like in the Real World version of the field.
With luck, you'll run into something that's a problem for your employer, and potentially a thesis topic worth pursuing professionally.
With more luck, you'll be in an environment that lets you work on your masters part time (3yrs in my case) while collecting a full time paycheck. Very handy that paycheck - I could not have done this on much less than full pay.
With more more more luck, your employer might even pay tuition for you.
With more more more more more more more luck, you'll actually enjoy both your work and your area of focus.
I've been lucky.
Note: part time study & full time work cuts down on fun big time, and makes friends nag you for not attending all social events. Avoid losing friends and your sanity by taking time out, even if it means cramming a few days later.
Canada: 30 Million people, has a Space Agency and "une agence spatiale".
Australia: 21 Million people, no Space Agency
Crikey, a project like the Canadarm would be cool, eh?
Amen. Hoping for a long, stable uptime on a linux machine that does very intensive and sustained NFS I/O provde to be pipe dream for me. Things did get much better after applying the plethora of nfs.org patches, but you still get some awesome kernel failures.
But I don't care, because I have many machines accessing the NFS mount (mailboxes, btw). I lose one, and keep on ticking. If I lose one machine every 3-4 months for an hour, my service availability stays good - though maybe a bit slow depending on the time of day. I could have mounted the shares on a set of Solaris boxes, but the cost for knowledgeable staff would have been far greater than sticking with Linux. That's right, hardware & software are generally much cheaper than the people to manage it.
So I agree that the original poster's "13+ years" experience with Linux is either a troll, or someone that doesn't have anything but simple use cases for his champion OS.
Individual components of a computing infrastructure will fail. I don't care if it's a $500 compute node, or a $20M disk array. You have to assume that this failure will occur in your design. Availability comes from design with this intent, and that sort of design is expensive.
It always comes down to dollars! As a business, you generally permit the expenditure on highly available design when it has a strong business case. Will you lose $1mil in revenue because of a string of outages? If the probability is very high that the answer is yes, then it would be reasonable to secure $300-400k to remedy the situation. If the highly availabe design costs you $300-400k, but the expected losses from your flaky infrastructure are $50-100k, the money will not be spent, regardless of how many times you whinge on Slashdot.
And so, we accept these average performing, generally there services because we consider it good value for the dollars we pay. We complain that it should be better - sure - but we don't change providers because of the dollars involved.
This is for windows operating systems only. The name may sound ungainly, but the software (particularly the recent v3.1 refresh) works really well for this sort of use case. Pricing is approximately $50/license, available in 25-packs direct from IBM, or in smaller increments from a reseller. Very good value for money, and I say this as a satisfied customer.
o ntinuous-data-protection/
http://www-306.ibm.com/software/tivoli/products/c
Backs up to network drives, WebDAV folders, or tivoli storage manager servers. The first two will be applicable to small businesses.
The software monitors the I/O drivers, and just copies changed blocks once an initial synch has been done. This ensures that only the changed data is pushed over what can be a preciously network link.
It can also simultaneously keep a copy of the protected data in another folder/directory, allowing for immediate restore should a file get corrupted. Very handy stuff.
The most challenging element with the setup then becomes getting a quiesced copy of the database files. This can probably be acheived by having the administrators write a small script to stop MSSQL, run a manual backup, then restart MSSQL. A bit annoying, but backing up MSSQL live is normally the realm of far more expensive software.
I would suggest that you are uninformed, and do not run a high volume mail system.
I'm responsible for a mid-sized mail system that receives an average of 10,000,000 connection requests per day. A good RBL is worth a lot to my employer.
We use Spamhaus xbl-sbl, and Trend Micro's Network Reputation Service - which is a combination of the more static RBL+ (of MAPS fame) and the highly dynamic QIL list.
Together, they drop approximately 92% of inbound connections to the SMTP server farm. This is a lot cheaper, computationally and financially, than using the lists later on in a content filtering stage. Without these RBLs, we would require ten times the CPU power to move and filter the messages that the dropped connections would undoubtedly attempt to deliver.
The RBLs allow us to provide customers with good to excellent filtering, at a tenth of the infrastructure cost that would be required without them, subscription cost to the two lists included. When we use a standard server build that runs approximately $15k/system, plus another $10k/system to rack, power, and cool it over it's lifetime (~3yrs) that's almost $450k saved over 3 years! And I'm not counting the bandwidth saved here, which is a substantial savings when buying international transit in Australia.
But the best part about the whole thing is the recorded number of complaints. I'm up to 10 in the past year. Even if the reported to unported ratio is 100:1, that's pretty excellent given the size of our customer base, and it's makeup - a lot of businesses that will complain if mail is blocked. Most problems were due to the QIL being a bit trigger-happy with listing other major Australian ISPs. No worries - it can be configured to whitelist by country, ISP, and arbitrary IP ranges. Fantastic.
Only a couple of complaints from people running mail servers behind DSL, in a residential (marked as dynamic) range. To these people I have one message: pay up to get a static (aka. business) grade service, co-locate your mail server, or get a real provider to be your mail host. Most spam comes from zombies sitting behind dynamic IP blocks - this is why they get dropped.
The final nicety from subscribing to these lists is while their support is good if you're a non-customer trying to be delisted (6-12hrs, tested prior to subscribing), their support is excellent when you're a customer. Quick to get spam evidence, quick to fix problematic listings of our systems _if the work has been done to clear the source_!
In summary:
1. spam still gets through the system. Now seeing 3-4% of connection attempts resulting in a delivery to a customer mailbox. Without the two RBLs on the front end, much more spam is seen because content filters are far from perfect.
2. Contrary to your assertion, list sharing is quite low: about 50% of the addresses are common between the two lists. In other words, we get about 60% connections dropped per list, for an aggregate of that 92% figure. If you assume that some spam sources are prolific, it indicates quite a bit of novel collection on the part of each.
3. A well run list isn't run by a schmuck. It's run by a company, with customers who pay it to do a good job and err towards reducing false positives. If you want schmuck, use SORBS.
I run a mail system that pushes ~3million messages per day. Not huge, not small.
We have thousands of domains pointed to our mail servers and secondary MX servers. Looking at the long run stats, I'd be tempted to completely disregard this technique.
When we take a primary down for maintenance, the secondaries and alternate primaries (same weight MX) see the load almost immediately.
I second the opinion that if this has any effect, it's only for low volume applications, with few/one domain.
We generally see more hits straight to the secondaries by spammers hoping for less rigorous checking. It would be interesting to profile IPs connecting to secondaries without being seen at the primary assuming a primary is always available - I bet that a very high percentage of these connections to secondaries could be viewed as spam.
The problem remains that most tricks of this sort - including greylisting - are eventually circumvented by spammers once the trick gains critical mass. Lets not forget that there are a lot of broken, yet not open relay, mail servers out there. Good engineers and administrators quickly find that Jon Postel's words ring true with their customers "Be liberal in what you accept, and conservative in what you send." - don't let your RFC enforcing configuration be responsible for delaying/blocking the delivery of that big contract your PHB was waiting for!
I have a love/hate relationship with Berkeley DB. This comment applies to OpenLDAP.
...), and if it gets corrupted, you'd better have a backup.
It's moody (DB_CONFIG anyone?), it's fast, gets reliable somewhere after many minor releases (started to trust 4.2.52, 4.3.25,
I agree with your point, in theory - RDBMS datastores could offer a lot of flexibility, and eliminate many data redundancy complications. In small-ish implementations, you may be fine.
The implementations I've seen are a different animal.
1. Berkeley DB is fast. When you're issuing a lot of reads(3000+/sec/replica), across what is already a large farm (20+) of replicas, BDB means less hardware, hence far less cost than any RDBMS datastore.
2. RDBMS backends for OpenLDAP aren't as well tested. This matters when your database drives your email, authentication, authorization, and address books.
But I agree that the RDBMS should be the _authoritative_ data store. It should populate your LDAP directory. Yes, that's easier said than done. The benefits of this are great though - flexible lower throughput data for the applications that can use it, low data redundancy ( if you've designed both your RDBMS and LDAP schemas properly), blazing read speeds, and excellent service availability.
I completely agree with you, and am completely baffled by the article's ascertations.
I work for a Melbourne ISP, and can assure you that finding skilled operations and development (two different roles there!) people is difficult. Our salaries are above average, the work varied, yet we still generally find a glut of skilled people.
And to answer those suggesting that we employ junior personel and train them up -we do. Though you can't expect to succeed as a company with one or two senior people and an army of juniors.
Though I can't say that this is a problem just in the IT industry. Australia's immigration laws are almost draconian, and their quotas are too low. Really. I've had chats with people in the engineering, legal, and architectural fields - all are looking for more experienced staff to balance their junior ranks, and are willing to pay for it.
Come on Australia, help your booming economy - increase the skilled migrant quota, and drop the required score!
The article was discussing the Open Power systems, i.e. OpenPower 710, 720. Quoth the IBM literature, they have been optimized for linux, and ship with Linux only. Running AIX and OS400 on them is not supported, and probably prohibited by some evil trinket :)
The POWER chip is a different story, and yes, is availble in other lines of IBM servers that do run a wider range of OSes.
Virtualization is your friend, but don't get the sales people started...
You can buy power from... IBM. And it's not cheap. And it doesn't run AIX, only Linux. Sort of. Many applications require some porting love, as per the bounties on http://www.linuxonpower.com/
r y/l-pow-portsolaris/
I generally like what IBM does, and use their x86 servers, storage, and software.
But "Open" is pushing it here.
I'd never be able to justify a recommendation to buy Open Power, that is, unless the sales guy left a flashy car in my parking spot...
Jonathan Schwartz (Sun CTO) had it right when he noted that that was as silly as them shipping Open Sparc boxes. Mind you, there are Fujitsu SPARC64 chips, and OEM sparc-based system builders.
Of course, IBM is just loving Solaris, particularly Solaris 10. Some assistance in your Solaris to Linux on Power migration? http://www-128.ibm.com/developerworks/linux/libra
(Though it is a well written piece - good quick guide to Linux and Solaris system calls, signals.)
Ha ha, funny troll.
You seem to be confusing the market that this thing is targetted as. This is Storage Area Networking, normally applied to systems for who's downtime cost far more to the company than this disk.
First, it's fast disk. Fibre Channel drives, using 15 000 rpm (up to 146GB now?), or 10 000rpm (300GB) disks.
Second, it's expandable. Just add extra drive chassies on the expansion loops.
Third, and the reason people buy these, is that it makes managing storage for 10s to 1000s (DS8000) of machines simpler. Only allocate the amount you need, but grow it easily without the hassle of dealing with normally under utilized scsi system disks.
This equipment is for "big time", highly reliable, yet highly redundant computing. That costs money. Your suggestion is for cheap cheap disk - and you should be looking at someone like www.infortrend.com if you had a $5k budget and wanted SATA-to-SCSI. The dual AMD and 4GB ram is a waste in your config.
...but consider stuff like GCJ, Kaffe, Pizza, etc. The Java community has survived them;
Sure, because in production environments, Sun's JVM drives the code.
Sun has to be careful about the open sourcing of Java. The language could use the innovation and backing that an open license could provide, yet the last thing any user or developer needs is for code that looks like Java to require a specific (non-Sun) virtual machine to run properly.
There is no need for packages like those in Debian stable who require 'kaffe' and not 'java-virtual-machine'.
These guys make a small machine that has a fully silent option with the
The boxes are nice and compact, with 2 PCI slots which is useful for adding an extra ethernet or DSL card. Check it out.
On that topic, Traverse also sells one of the few PCI DSL cards who has active Linux and *BSD driver development. It's low form factor, which is nice for this sort of work.
Given your environment's description, it would seem like moving to Debian would be a good choice.
1) You have no existing support contracts to honour
2) you're running an OS which no longer has vendor/distro supplied patches. There is the fedora legacy project, but I'm unsure of it's status.
3) It's a lot less hassle to run one version of one distro, than multiple versions of one distro (i.e. RH 7.x/8/9).
4) You can put custom packages or backports in a private repository for those machines that really do need them.
Like all decisions of the sorts, ensure that it's good for the business, and that you have the support of your peers.
I spent several months looking at a sole successor for our set of 150 linux (mostly Debian, some RH), Solaris, and Windows systems. We had been running backups with a hard to manage mash of rsync's, Amanda, Legato Networker, and Veritas Netbackup.
At the end of the day, Tivoli Storage Manager bested out Veritas NetBackup. In testing, I knew that I could run the tivoli code under Debian. But when you're considering a mass Debian deployment of code designed for RedHat/SuSe, you drop any thoughts of using Alien other than for quick tests. You have to find an IBM support team that will work with you should you run into trouble with a non-supported distribution such a Debian, but you also have to realize that at the end of the day, they will run on best effort because they have not tested their code on Debian.
So far, things are working well with Debian/stable systems. There was a bug in the initscripts package that caused a bit of heck on the very few Debian/testing systems that I was running, but it was overcome with 30 minutes worth of work.
Still, the bottom line is to do what's best for your business, not what's best for you. We chose Debian because it's very stable, and relatively easy to support. The only problem with it is explaining to vendors why we don't use RedHat Enterprise or SuSe Enterprise (namely, dollars). The IBM people are very comfortable with SuSe and RedHat - which means your troubles will be resolved quickly. You will find some very intelligent IBM people that will help you out with non-standards such as Debian, but you will pay for it in time-to-restoration if you aren't fully on the ball.
For most companies, software is a tool which supports the generation of revenue. Zero cost software is of no use to them if downtime/support wastes more money than commercial software, subscriptions (RH/SuSe), or support contracts would.
In your case, it seems that you're currently running an enviroment that IBM fully supports, and is supported by your linux distributor/vendor. Don't be dumb, stick to what you've got.
You could "upgrade" a reiser3 FS to a reiser4 FS if the partition was software raid-1.
/olddir; find . -xdev | cpio -pdmu /newdir ]
I've done ext2 -> reiser3, and ext2->XFS with this before on production servers.
See the software RAID howto for specifics, but:
1) unmount, stop and split the mirror
2) mkfs.reiserfs4 one half of the mirror
3) mount the new and old halves of the mirror, and copy data from the old half to the new half
[ cd
4) rebuild the mirror using the new half as a source, attaching the old half once created.
Of course, it's probably less work to just back the disk up and blast it. Although it could save you time wirh boot disks, and unmountable partitions. Heck, you wouldn't do this without a backup anyways, right?
Whoa. You're comparing RIAA tactics to non-free (as in _libre_ and dollars) software vendors.
Your comparison is totally inappropriate.
With per-cpu licensing, the assumption is that the software can do more for you on a multi-cpu system, hence you pay more for it. There's nothing terribly dodgy about this.
After all, whey you're paying for performance, the vendor (and buyer) wants to find a useful billing metric that's easy for everyone to understand. Anyone who's dealt with Veritas's 20 or so tiers will appreciate this.
Per cpu is the way to go then. The customer maximizes their investment when running on the fastest CPUs available, which isn't normally a big deal when the cost of the software far exceeds the cost of 3.2GHz Xeons or equivalent Athlons.
Per-cpu also solves the issue of pricing a single-cpu x86 (little $), versus a 32+ cpu sparc box (big $), versus 32x single-cpu x86 clusters.
So, when multiple-core chips come out, they'll essentially be multi-cpu. easy. Use them, pay more.
Because of competition from free ($/libre) software, licensing arrangements have gotten a lot more sane in the past couple years. Vendors are trying to stay away from that line in the sand where it becomes cheaper to re-train,re-build,re-deploy than to re-license.
This is very much unlike the RIAA,MPAA, and their friends in other countries who see it fit to take a much more extortive stance. Remember that most vendors let you move a per-cpu license around to different OSes and architectures, something that surely can't be said of the entertainment industry (oh, you own this on videocasette? You can have the DVD for media & packaging costs, or just download the content from http://videos.com)
Let's not forget that the freedom in documentation that you want is more than many, including myself, would consider appropriate.
To be 100% DFSG-defined free, some have argued in debian-devel and debian-legal you should be able to edit, and redistribute your edits of any documentation.
Sounds ok when you first think of it, which is probably why the general resolution that proposed that changed passed. But then you realize that:
1) the docs include standards, like RFCs, which _should not_ be changed and redistributed, less confusion ensue. There is a formal process for contribution and review, but just editing the docs isn't it.
2) the docs include license texts, like the GPL, APL, etc. The condition of using and redistributing most of the code in debian/main, including such useful things as the kernel, glibc, gcc, g, is that the text of GPL be distributed along with it. However, the GPL text itself isn't 100% free from the DFSG's point of view because it once again cannot be altered and redistributed as the GPL. And bingo, you're stuck! The GPL can't be put into non-free, because is presence is mandatory, but good luck in having the FSF alter their license.
I have nothing against a free _software_ interpretation of the DFSG, but there are good practical reasons why the same freedoms cannot be applied to the documentation.
----------seperate point for discussion-----------
Interesting thing - wait much more than 6-12 months for Sarge, and most serious debian installs will be running production systems with a heavy concentration of backports.
And with backports, there are less eyes on the package's code level, and less eyes to notice that an update may have been released to plug some security problems. But there's the trap: (1) use testing and have a too volatile OS, (2) use stable + backports and get a functional os, that's generally secure, or (3) use just stable and get an OS that in time loses the ability to deliver 'standard' features, i.e. functions that have been available for more than a year.
As per another poster, I'm referring to discussions in debian-legal regarding the status of those licenses *for Debian*.
Indeed, some Debian people have been trying to get the FSF to see things their way and alter the GPL to make it DFSG compatible.
Why? There are DDs that are more radical about free-as-in-libre than RMS.
Again, a great distro, but with interesting internal politics.
I love Debian as a distribution. As with all things decided in a democratic fashion, it will never be everything to everyone - not even those hoping for '100%' libre.
Nevertheless, there's a few things that I wish the project would relax on a bit, w.r.t the DFSG.
-licensing. APL and MPL licensed software is potentially heading towards non-free. Why? Because of the clause to the licenses that states that you abandon all patent claims when contributing code. To me, this is fantastic, and stops companies from contributing code, then making turning about-face and suing everyone that uses it once a patent for a mechanism used therein is granted a patent. I view these licenses as "more-free" but there is much disagreement. We may not like software patents, but ignoring their existence is no way to handle the issue.
-the dissident test. This terribly frustrating test causes problems with modifying code and documentation for many packages, in the hope of ensuring that any moral dissident does not have to be bound to exposing their identities if they alter/contribute code. It's a funny thing, because dissidents normally operate outside the boundaries of their region's laws, purportedly to eventually have these altered. Why accomodate people who, by definition, will ignore your rules when they see it fit?
Anyways, I'm glad for this vote, as it means that we can get an updated stable soon-ish, something that is long overdue.
Your problem is entirely with Debian's approach to Java.
.bin files that you get from java.sun.com.
I develop and assist in maintaining over 100 Debian systems at work. The debian packaging tools are fantastic. Tack on a few small scripts, and you could expend very little effort on maintaing hundreds of machines.
Until you get into Java, which just about every enterprise is. If you're serious about it, you drop almost everything that the Debian project does w.r.t java, and add the following to your sources.list file:
deb http://z42.de debian/
deb-src http://z42.de debian/
Get j2se-package, which nicely builds sun-j2sdk1.x and sun-j2re1.x packages out of the Java
You then throw these packaged into your in-house repository. Redistribution of a modified JRE or SDK (like a Debian package) is prohibited by Sun's current licensing terms.
You then might want to rebuild any Debian java packages for your repository using Sun's Java, and not Kaffe or any other hacks. When developer's complain that certain classes aren't working, answering 'but there isn't a DFSG compliant jvm that will support them' is generally not the way to promote harmony at the office, or to guard your job security. RMS disagrees with this, as per his article on 'The Java Trap', but I work in a world of reasonable compromise.
Of course, being a serious enterprise user of Debian, your in-house repository will contain a heck of a lot more packages that Java. Probably because you're running Debian/stable, with a volley of backports to support more recent versions of certain packages. OpenLDAP 2.1, MailScanner, SpamAssassin, and Apache2 come to mind.
I love Debian, I just hope that the bickering over the latest version of the DFSG doesn't draw developers away, or critically delay the release of Sarge.
Did you know that the new DFSG _should_ require many standard packages exit the main distribution and enter non-free? We're talking anything MPL'ed, APL'ed, potentially reiserfs(*), and if a few posters on debian-legal and debian-devel were to be believed, even GPL'ed code (the pre-amble).
(*)Because of the mkfs.reiserfs advertisement - you get an amazing filesystem for _nothing_, yet you complain because the funding agencies are shown while mkfs is running? Get real.)
3.0.0pre1 was made available last week.
i ld/3.0.0_change_summary
It will apparently take another month or so to finalize the weighting of the rules.
I've put 3.0.0pre1 on a production system that filters ~350k messages per day. With some tweaking of the RBL, bayes, and AWL rules, it is much (~10%) more efficient at tagging spam than 2.63, which I'm running on a parallel server that also sees ~350k messages/day (load balancing is your friend).
More info: http://www.au.spamassassin.org/full/3.0.x/dist/bu
Imagine being somewhere where there'd be no want to make firearm ownership a right.
That's where the arguments for ownership fall appart.
That's where the worst thing the media can report on is a bunch of kids attacking one another with knives and fists, never really being a problem to the bystander 100m across the park.
That place is anywhere where there is no right and hence no supply to meet the demands of irrationality. You would make a fine candidate for working anywhere, save a warzone.
An armed citizen can lose his or her cool and do everlasting damage. An unarmed one can have everlasting impact.
My major torment in Melbourne is not being able to get a consistently fantastic cup of drip coffee.
An extra large cup of the fresh stuff used to cost me $1.50 cnd, for half a liter of caffeinated goodness.
Now, a 'large' (250ml) flat white or long black sets me back $3.00au. ($1cnd ~= $1au at the moment).
The only Drip coffee alternative is Starbucks, which doesn't bother with non-espresso based coffees until 10am. The horror.
Back to the topic at hand, in reasons to re-locate:
America: 2 weeks vacation if you're lucky. Low tax.
Canada: 3 weeks vacation rather standard. Higher tax.
Australia: 4 weeks vacation guaranteed. Tax higher than CND, but on it's way to dropping to equivalent rates.
But hey, I could care less about taxes. Give me education and healthcare that works, cities that are clean, an approach with firearms that doesn't make ownership a right, and I'll happily shell out between 30-40%.
True, both the Canadian and Australian laws haven't been tested as per my first comment, but the impact of breaking the Canadian one has far less repercussions should a judgement be issued against the users of material covered by the Act.
Now that I live in Melbourne, it frustrates me that I can't legitimately backup the music that I buy, or convert its format to something more suitable for my mp3 player.
That citizens (generally) blazenly ignore this law is a different issue - the point is that they shouldn't have to.