I'm not disagreeing that its at least partially the customer's responsibility to figure out what's going on.
What I am disagreeing with is Sun's policy of claiming that an UltraSparc IV != 2 UltraSparc IIIs. Instead, an US IV is somehow 2x faster than an US III, "because Sun is just that good".
The datasheets say that the UltraSparc IV is a CMT processor, yes, with each processor capble of handling two threads, but show me where that datasheet says "two execution cores". In fact, take a look at the US IV datasheets and watch as the Sun folks dance like crazy to avoid ever saying, "multiple execution cores". They say things like, "simultaneous threads", or "based on two ultra sparc III pipelines". If Sun simply stepped up and said, "Look, we've smooshed two ultrasparc III processors into one slot, so you can double your CPU count in your existing frame", I would be content.
And I'm not complaining because I feel like Sun has cheated me or my company. In fact, that policy only works to our favor - we get a number of interested customers who feel like Sun has treated them unfairly and want to move off Sun. I'm offended because as a business person, I do not intentionally mislead my customers as to the nature of what I do, something I know for a fact Sun sales reps have been doing.
IBM has been doing multi-core chips for a while, and they've never tried to claim that they were one processor. They say its two - why is that so hard? If you want to claim Niagra is something fundamentally different, you can make that argument. But the US IV is really just two USIIIs put together, nothing more, nothing less.
The last thing - right from Oracle's licensing agreement:
"For the purposes of counting the number of processors which require licensing, a multicore chip with "n" processor cores shall be counted as "n" processors."
Oracle's been talking about reworking their licensing for a long time, and I agree licensing by core is sub-optimal. However, Oracle is being forthright that they charge by core, while Sun is _hiding_ the fact the USIV _is_ a multi-core processor.
Sure, Oracle are the ones charging per processor core, but Sun is the company that is selling this upgrade as a painless, cost-effective way to upgrade their infrastructure. I firmly believe they are being negligent in not warning customers that this is a multi-core architecture - if you go to Sun's site and look at how its sold, they pitch it as one processor, one core.
Imagine you're a customer - you spend $100k on Sun's new processors as a "painless" 1-1 upgrade, and suddenly find out that the first 100k has put you on the hook for 150k in new licenses. Wouldn't you feel like you'd been misled?
I was only talking about the USIV, not the Niagra. Honestly, I would be willing to wager a (smallish) amount of money that Niagra is the last chip architecture Sun releases.
And actually, this makes me so grumpy that I forgot the whole other piece.
Despite the fact that Sun markets the UltraSparc IV as a single processor, software licensors like BEA and Oracle require that you license their software PER CORE. This means that a "4 processor" UltraSparc IV requires 8 processor licenses for Oracle or Weblogic.
Sun never tells you this, and consequently a lot of people suddenly get tagged with additional licenses if they get audited. BEYOND that, Sun tells people that they can "double their performance" by replacing all of their UltraSparc IIIs with UltraSparc IVs, not explaining that they are doubling their performance because they're doubling the number of processors, AND that doing that upgrade can put them on the hook for literally hundreds of thousands of dollars in software cost.
We've seen a number of companies get bitten by that, and it is downright disingenuous of Sun.
CMT is nothing more than multi-core processors. Sun is using the marketing idea of CMT to hide the fact that the UltraSparc IV is nothing more than two UltraSparc III cores on one chip.
One way to look at this is Sun maximizing their existing engineering efforts. However, by marketing it as some revolutionary feature advance, they're implying that they've done something new and exciting, as opposed to something that IBM is already doing and AMD and Intel are working on.
Beyond that, Sun and Fujitsu have a co-manufacturing and R&D deal now, confirming something those in the enterprise space have been saying for a long time - Fujitsu was making better Sun servers than Sun.
Plus Sun killed plans for the UltraSparc V, leaving only the Niagra. They have the Opteron line pushing up from below, and rapidly evaporating sales at the high end. They're resorting to marketing gibberish to add new features to the product line, while simultaneously offloading R&D and manufacturing to a partner.
Remind me again why Sun is in the hardware business?
Whoa, whoa, whoa - Oracle not innovative? Oracle is, in fact, doing a huge amount of work to drive their database and application server forward. Here's a list of some of the things they're doing that I have seen working in test environments:
-Volume management - that's right, the database with an integrated volume manager. Self-tuning, self-healing, online migration and mirroring - what other database has that?
-distributed clustering over high-performance interconnects - okay, db2 has this, but does it differently. With oracle 10g, nodes can actually share their memory purely in hardware over InfiniBand to improve performance and reduce latency for clustering.
-Wrote their own clustered filesystem - its not the greatest thing since sliced bread yet, but Oracle took a look at the clustered filesystems available for Linux and decided to write their own specifically geared towards Oracle.
This is just the start - I'm not even touching on some of the data representation things they've done with the database and application server. While Oracle made a very smart move porting to Linux, they continue to be leaders in pushing Linux forward as an enterprise platform, even working around Linux's limitations where they feel they have to.
Now, I'm a touch biased - my company has a database appliance product based around some of these features I just listed. But there's no question that, after having worked with a number of different nameless database vendors, Oracle has the most comprehensive, forward-looking, and innovative insight into the future of the enterprise database in the industry.
It's not that easy. It's one, a case-by-case situation and two, not so much a question of necessarily doing either, but rather level-setting expectations for your business and the client.
You have to look at each problem/project/opportunity as a chance to do the following:
-Make or lose money -win or lose respect -gain or lose political power (this is situational and more to do with you and your team than your company as a whole)
How you deliver a solution is dependent on what of those three things you're going to focus on. The unsophisticated answer is to say that "making money" is the most important - but remember that winning respect from a client or business unit can make your team far more money over the long run sometimes. The guidance as to what you will be focusing on will often come from management/sales, as power tends to be concentrated in their hands.
The two options you speak are Quick & Dirty and Long & Comprehensive. The most important rule is: Once you deliver the Quick and Dirty Solution it is THE solution. You will never be allowed to go back and fix it unless it is hideously broken, in which case you are in trouble anyway.
So, you have to look at the amount of money you expect to earn from this client/LoB, both short-term and long-term, your current and desired respect level from same, and the amount of political pull you have from accompanying lines of business. If you're under a lot of pressure from management to deliver a Q&D solution, with enough political power and respect, you may be able to pull out a better solution.
Cover your butt. Emails, phrased in a friendly way, just mentioning potential problems, can go a long way to helping smooth things over when things go to hell. Read about managing people.
Now, the more overarching answer is that the quick and dirty solution is almost never the real solution, unless your idea of quick and dirty differs vastly from mine. It's just not the right way to do business, and will inevitably end up costing you and your customer more money in the long-term, and heaven help you if your customer figures it out.
I work for a company that's building a product, and while we're under deadlines just like everyone else, we simply draw a line in the sand about what features won't be implemented rather than half-assing the ones we do. And just like everything else, its a tug of war between the people building it and the people selling it.
The upshot of all this is that you have to manage the expectations of those that are in control. You have to say what will and won't be implemented, what corners you're cutting, and what the possible implications of those things are. It becomes far more about managing and dealing with people than building technology. I bet in your organization there are managers that somehow consistently manage to get their way - watch what they do, whether its simply presenting problems a certain way or they play golf with the boss - it could be anything. Learn from watching them how to manage the people that create barriers to your building a proper solution.
You might want to look for Netapp FC(xx) disk shelves. They're normal hot-swap fibre channel JBODs. They're also very expensive, but if you get lucky you might see one sans drives and get it for much cheaper.
I'm questionable on whether this is on-topic, but it seems relevant. My company, a startup in NYC, is looking for a college-level intern to work with us on developing our software and building our our infrastructure. Here's some of the stuff we work with:
-Linux -Oracle and a bit of SQL Server -Cisco -C, Perl, C++, Java, a bit of ASP
While we can't offer money (we're a startup, after all), here's what we can offer you:
-A letter of recommendation. (we write well). -A chance to actually complete significant projects with assistance from the rest of us. This won't be simply making cables and fetching coffee (though there will probably be some cable making). -The opportunity to work with an extremely talented group of individuals who have built several very large-scale systems and application infrastructures.
If you live in the NYC area and are interested, send me an email, and I'll give you more details.
Availability checks for domain name registrars never hit the root servers. The registrars connect directly to the SRS (Shared Registry System) and look up records there.
It would be silly to use the root servers as a basis for availability, especially since the root servers know nothing about individual domains, only TLDs (the root server zone file is less then 50k, iirc) . But even assuming you meant the DNS servers one level down(like the GTLD servers that handle.com,.net, and.org), none of them refresh in real-time, so you could be registering a domain that had actually been taken 6 hours previously.
Thanks, Matt
ENUM is much more than just a global ID.....
on
U.S. Endorses ENUM
·
· Score: 1
It's a fundamental bridge between two different worlds - the PSTN and IP networking. The real utility of this is not so much the one-id-for-every-contact, its things like pstn->ip telephony->pstn. Some of the applications include:
-Combining with SIP to provide global number portability - no cell phone roaming overseas, etc. -Reducing international tariff burdens by terminating calls in countries with better tariff agreements with the destination (i.e. it is much cheaper for the UK to call France than for the US to call France, so you route the call over IP to the UK, then go PSTN from the UK to France). -Simplifying carrier-transit agreements
And these are just the ones we've come up with so far. It's worth noting as well that part of the ENUM spec is the use of a new dns record type - NAPTR, which allows regular expression functionality in DNS RRs...the mind reels at the possibilities.
For the people who want to know about e164.arpa, that is planned to be the global TLD for ENUM. Thanks to the miracle of DNS delegation, each country code can be administered by the country itself. The only one that's really complicated is the US, since it includes other countries in the +1 country code.
The problems with ENUM are primarily that most of the phone companies have solved some of these problems with proprietary (generally inferior) solutions. They're slow-moving to begin with and don't immediately see the utility in implementing ENUM. It's mostly up-and-coming CLECs and VoIP companies that are looking to ENUM to both generate revenue and save money.
Plus, there is already enum support in a variety of products. Cisco's VoIP suite includes ENUM support (only the SIP line, not the H.323), so you could roll out ENUM within your organization. I have a feeling that ENUM will be much like BGP or DNS is today - 95%+ of the population will either use or benefit from it, and never be aware of its existence.
Thanks, Matt
Easy - by not using blade servers....
on
Open Blade Servers?
·
· Score: 5, Insightful
We won't see open blade servers for quite a while, if ever. Normal servers are only "open" because they use a common set of interconnects (standard power, ps/2 keyboard, 100BaseT), etc. On a blade server, you have to unify all of those interconnects in a hot-swappable fashion. The result? A customized connector and backplane architecture.
In addition, there's no incentive for companies to open a standard for blade servers - they'll make more money by selling the chassis and blades, as well as the management software that is generally required for these types of servers.
As far as Google goes, they rolled out their infrastructure for such a low cost because they did the following things:
1) didn't use blade servers(more on that in a sec) 2) bought in large quantities 3) bought generic/semi-generic servers (by which I mean "not IBM")
Not using blade servers was a sharp idea because the real advantages of blade servers come in certain particular situations. These include where power/heat/space is really expensive or where you need a lot of hosts without a lot of performance (like QA, staging and development environments). Remember, that while they use less space, power, etc., they also use laptop/low-power cpus and hard drives, so the performance can be lower, especially for i/o intensive operations. If you're not hugely space-constrained, using 1U servers will save you money in the long run.
"Using databases to manage concurrency (and a whole lot of other things) greatly simplifies projects IMO"
This is only partially true, and the "partially" derives from the scale the application is being built on. It's very possible to realize development time savings by whacking your mp3 playlist information into mysql rather than parsing out data yourself - but that won't work quite as well when you're indexing 30,000,000 mp3s.
Using a database will make WRITING your application easier - but the job is not done when QA gives it the green light. That application has to be maintained, either by you, or by the customer (and since we're talking about J2EE server applications, we'll presume its by you).
Databases are expensive, not just in the cost of the software/hardware, but in the cost to manage them. The whole model of tightly coupling data together in one place is what allows you to realize development savings ("Rather than write an efficient Java function to find every person who lives in the specified state in the same zip code, I'm going to let the database figure it out with two lines of SQL!!") - coupling, though, also forces you to have big databases - you won't get any benefit if your data is spread across farms of different servers. When I'm referring to databases, btw, I mean OLTP-style databases, as it is very rarely acceptable for web applications to have data warehouse-equivalent delays in data retrieval.
As your database increases in size and complexity, the cost to operate it increases EXPONENTIALLY. So, while dedicating a 2-processor linux box to database traffic is highly cost effective (say $2000), the cost of dedicating a 10-processor, 64-bit Sun box to database traffic is not (market price $100k-200k depending on new vs. reman, discount structure, etc.). Likewise, software and storage costs grow in a similar fashion - two 36GB scsi disks will cost you a few hundred dollars, while a 3.6TB enterprise storage array will cost you in the hundreds of thousands of dollars. Management costs as well begin to come into play - it takes a very different skill set to run a 2GB database from a 2TB database.
If you expect your application to grow exponentially, relying on a database will make your costs grow exponentially as well.
The right way is to only put long-term, persistent data in your database. Nothing transient should ever hit your database, ever. Even old and unused persistent data should be periodically dumped out to tape or to a data warehouse and purged from your production database. Scale horizontally, not vertically. Put yourself in a situation where when your site gets slow, you need to buy another 5 linux web/application servers, not forklift upgrade your 4-processor database to an 8-processor database.
This fundamental flaw in the all-in-the-database system is why companies like Oracle have invested millions of dollars in allowing their software to scale horizontally - in effect, to get the best of both worlds. But, you still have the management problems associated with large centralized storage, backups, plus licensing costs, etc.
None of this is to say that centralizing business intelligence in a database is always a bad idea. But I have worked in situations where people put intelligence in the database with the best intentions, only to discover themselves victims of their own success. Look at google for possibly the ultimate example of de-centralization. They do nothing BUT scale horizontally, and while that isn't necessarily the answer either, it shows it can be done.
Here's what you have to ask yourself as you write any serious, enterprise-grade application: 1) As my data grows, does my revenue grow exponentially (or even linearly) with it? 2) How long does this data need to persist? 3) How can I group my data in such a way that groups can be completely uncoupled from each other within the database as my environment grows? 4) How can I accomplish my purpose without touching the database?
Of those, 1) is the longest term - very rarely does revenue grow at the same pace as data, so the cost of data storage has to be kept down. 2) and 3) is pure practicality - never store anything that you don't plan to eventually delete, and 4) is getting yourself into the mindset that the OLTP database is the location of last resort for data.
Phew. I've been wanting to get that off my chest for a while.
I'm afraid you're extremely misinformed. Internic did not become register.com....it was always Network Solutions, which was acquired by Verisign. Register.com is a competitive registrar in its own right (the first competitive registrar ever, incidentally).
In addition, ICANN has nothing to do with the domain name related spam you receive. In fact, the WHOIS agreements ICANN requires explicitly forbids the use of Whois data for commercial email purposes.
In addition, the beauty of our DNS architecture as it stands today is that whatever protocols we want can develop and be completely uninvoved with ICANN. All ICANN has to do with DNS is their operation of the roots, which means a small number of NS records delegating to the TLD servers. It would be extremely difficult for them to do something really evil with them.
There are a number of companies that make equipment to handle this type of situation - NCipher is the only one I'm familiar with specifically (I've never used it - just evaluated it).
Basically its a PCI card, or a little box with a SCSI connector on it (don't ask), that you plug in/hook up to your server. The card/server can then store keys internally and perform operations on data passed in & out of it. So, generate a key, store it on the card/box, write your app to pass CC info to the card library, statically link the library into the application and then erase the library.
To protect the information from physical tampering, the card and the box implement FIPS-grade protection. The card is level 2 (iirc) - the chips that store the data have a big thick black cover on them. Should you tear that off, it creates a chemical reaction that destroys the chips and their data. The box can be FIPS level 3, which means if you pick it up or otherwise shake it, the keys are destroyed.
Key escrow is handled by built-in smartcard readers, and you can do secret sharing (i.e. requiring two-of-five people to insert their smartcards to load the key).
It's not cheap - the lowest-end model is 11k, as I recall, but it gives you what you need. It's a secure mechanism for maintaining secret data.
For an extra level of paranoia, use LIDS or Argus Trusted Solaris, and use ACLs to only grant your application permission to access the device files for the key storage. That way, even if someone wrote an app and linked it against the key management lib, they can't get at the device instance to do anything.
Just depends on how much you're willing to pay and go through (hassle-wise) to get real security.
An old friend of mine who worked for an ISP that shall remain nameless was one of the engineers working on the webcast of a Very Large Event (tm). They needed to deploy all of the architecture, etc. needed to broadcast the video to thousands and thousands of people worldwide, and they were under a tight deadline.
So, there were a multitude of servers, network gear, cables, etc. that all were shipped to the location. Most of it made it there okay. But a rather key piece - a multi-hundred-thousand-dollar Cisco 7513 that was to serve as the core router for the whole infrastructure, never made it to its destination. The shipping company sort of shrugged and apologized, but that still left the problem of how to get a new 7513 to the location in time.
Cisco was very helpful - promptly delivering a new 7513 on rush, but it was delivered to the ISPs offices. They opted not to trust it to the vagaries of shipping, and instead put someone on a plane, and checked the crated router as "critical cargo", supposedly the highest level of service an airline will give.
Well, they lost it.
It got put on a cargo plane to somewhere remote, and wouldn't be back for days. The people at the ISP were frantic. They needed a router RIGHT NOW, something they could get over there, and they needed some transport mechanism that would be foolproof.
So, they pulled a standby 7513 out of production, scraped together the needed linecards, put it on a handtruck, and drove it to the airport. Once there, they bought the escorting engineer two plane tickets - one for the engineer.........and one for the router. Of course, a 7513 is too big for coach seats, so they put the both of them right next to each other......in first-class.
History does not record whether the router had the chicken or the fish.
But, the router made it there, probably having enjoyed the in-flight movies and complimentary steamed towels, and cheerfully fulfilled its duty , pushing packets to and fro.
And then it was shipped back UPS ground, probably dreaming of its taste of the high life.
The holdup on IDN is based in the IETF - the protocol standard for IDN has not yet been finalized, although chances are good it will be at the next IETF in a few weeks. It would be premature and equally bad for ICANN to declare a standard outside of the scope of the IETF, where standards are supposed to be made.
And while Mara and Djbdns may support UTF-8 encoding within the DNS, as far as I know, that is not the IETF's proposed standard solution.
A better reason is that ICANN wants to demonstrate that it wants to be representative of the whole world. If they meet only in the US and EU, then they're Euro-centric, but then they meet outside of the US, and they're trying to party it up in Africa....can't have it both ways.
Also, one of the heads of the steering committee (I think - one of the heads of ICANN, anyway) is from Ghana.
I bought one of these and promptly traded it for an Ipod as soon as it was available.
The interface is good, the size is downright tiny, but the battery life is miserable. Perhaps the reviewer was using the 1GB microdrive, which actually has a lower RPM than the 340MB (which is what I'm using) and consequently gets a better battery life, but my NexII would last a max of 3 hours on 2 batteries.
Not only that, but when the battery starts to get low, the nex II experienced lockups and crashes. It was an extremely frustrating experience. All of this only applied to the microdrive - with a CF card, it worked great. But the whole reason I purchased it was for its microdrive support. I did everything their manuals and website suggested, but it didn't really help.
Oh, and another annoying thing - the "shuffle" feature will always sort the songs in the same order.
How can anyone verify the veracity of this without the domain name? I could type that up just as easily as you could. If you post the name, perhaps we can get to the bottom of this. At the very least, email it to me.
No way - if you're a large organization with a couple of thousand domain names, it costs you maybe 20 dollars a year per name to keep them. What's 50k to a huge corporation?
Slashdot Mirror
I'm not disagreeing that its at least partially the customer's responsibility to figure out what's going on.
What I am disagreeing with is Sun's policy of claiming that an UltraSparc IV != 2 UltraSparc IIIs. Instead, an US IV is somehow 2x faster than an US III, "because Sun is just that good".
The datasheets say that the UltraSparc IV is a CMT processor, yes, with each processor capble of handling two threads, but show me where that datasheet says "two execution cores". In fact, take a look at the US IV datasheets and watch as the Sun folks dance like crazy to avoid ever saying, "multiple execution cores". They say things like, "simultaneous threads", or "based on two ultra sparc III pipelines". If Sun simply stepped up and said, "Look, we've smooshed two ultrasparc III processors into one slot, so you can double your CPU count in your existing frame", I would be content.
And I'm not complaining because I feel like Sun has cheated me or my company. In fact, that policy only works to our favor - we get a number of interested customers who feel like Sun has treated them unfairly and want to move off Sun. I'm offended because as a business person, I do not intentionally mislead my customers as to the nature of what I do, something I know for a fact Sun sales reps have been doing.
IBM has been doing multi-core chips for a while, and they've never tried to claim that they were one processor. They say its two - why is that so hard? If you want to claim Niagra is something fundamentally different, you can make that argument. But the US IV is really just two USIIIs put together, nothing more, nothing less.
The last thing - right from Oracle's licensing agreement:
"For the purposes of counting the number of processors which require licensing, a multicore chip with "n" processor cores shall be counted as "n" processors."
Seems pretty clear to me.
Thanks,
Matt
Oracle's been talking about reworking their licensing for a long time, and I agree licensing by core is sub-optimal. However, Oracle is being forthright that they charge by core, while Sun is _hiding_ the fact the USIV _is_ a multi-core processor.
Sure, Oracle are the ones charging per processor core, but Sun is the company that is selling this upgrade as a painless, cost-effective way to upgrade their infrastructure. I firmly believe they are being negligent in not warning customers that this is a multi-core architecture - if you go to Sun's site and look at how its sold, they pitch it as one processor, one core.
Imagine you're a customer - you spend $100k on Sun's new processors as a "painless" 1-1 upgrade, and suddenly find out that the first 100k has put you on the hook for 150k in new licenses. Wouldn't you feel like you'd been misled?
Thanks,
Matt
I was only talking about the USIV, not the Niagra. Honestly, I would be willing to wager a (smallish) amount of money that Niagra is the last chip architecture Sun releases.
Thanks,
Matt
And actually, this makes me so grumpy that I forgot the whole other piece.
Despite the fact that Sun markets the UltraSparc IV as a single processor, software licensors like BEA and Oracle require that you license their software PER CORE. This means that a "4 processor" UltraSparc IV requires 8 processor licenses for Oracle or Weblogic.
Sun never tells you this, and consequently a lot of people suddenly get tagged with additional licenses if they get audited. BEYOND that, Sun tells people that they can "double their performance" by replacing all of their UltraSparc IIIs with UltraSparc IVs, not explaining that they are doubling their performance because they're doubling the number of processors, AND that doing that upgrade can put them on the hook for literally hundreds of thousands of dollars in software cost.
We've seen a number of companies get bitten by that, and it is downright disingenuous of Sun.
Thanks,
Matt
CMT is nothing more than multi-core processors. Sun is using the marketing idea of CMT to hide the fact that the UltraSparc IV is nothing more than two UltraSparc III cores on one chip.
One way to look at this is Sun maximizing their existing engineering efforts. However, by marketing it as some revolutionary feature advance, they're implying that they've done something new and exciting, as opposed to something that IBM is already doing and AMD and Intel are working on.
Beyond that, Sun and Fujitsu have a co-manufacturing and R&D deal now, confirming something those in the enterprise space have been saying for a long time - Fujitsu was making better Sun servers than Sun.
Plus Sun killed plans for the UltraSparc V, leaving only the Niagra. They have the Opteron line pushing up from below, and rapidly evaporating sales at the high end. They're resorting to marketing gibberish to add new features to the product line, while simultaneously offloading R&D and manufacturing to a partner.
Remind me again why Sun is in the hardware business?
Thanks,
Matt
Whoa, whoa, whoa - Oracle not innovative? Oracle is, in fact, doing a huge amount of work to drive their database and application server forward. Here's a list of some of the things they're doing that I have seen working in test environments:
.02,
-Volume management - that's right, the database with an integrated volume manager. Self-tuning, self-healing, online migration and mirroring - what other database has that?
-distributed clustering over high-performance interconnects - okay, db2 has this, but does it differently. With oracle 10g, nodes can actually share their memory purely in hardware over InfiniBand to improve performance and reduce latency for clustering.
-Wrote their own clustered filesystem - its not the greatest thing since sliced bread yet, but Oracle took a look at the clustered filesystems available for Linux and decided to write their own specifically geared towards Oracle.
This is just the start - I'm not even touching on some of the data representation things they've done with the database and application server. While Oracle made a very smart move porting to Linux, they continue to be leaders in pushing Linux forward as an enterprise platform, even working around Linux's limitations where they feel they have to.
Now, I'm a touch biased - my company has a database appliance product based around some of these features I just listed. But there's no question that, after having worked with a number of different nameless database vendors, Oracle has the most comprehensive, forward-looking, and innovative insight into the future of the enterprise database in the industry.
As always, just my
Matt
It's not that easy. It's one, a case-by-case situation and two, not so much a question of necessarily doing either, but rather level-setting expectations for your business and the client.
You have to look at each problem/project/opportunity as a chance to do the following:
-Make or lose money
-win or lose respect
-gain or lose political power (this is situational and more to do with you and your team than your company as a whole)
How you deliver a solution is dependent on what of those three things you're going to focus on. The unsophisticated answer is to say that "making money" is the most important - but remember that winning respect from a client or business unit can make your team far more money over the long run sometimes. The guidance as to what you will be focusing on will often come from management/sales, as power tends to be concentrated in their hands.
The two options you speak are Quick & Dirty and Long & Comprehensive. The most important rule is: Once you deliver the Quick and Dirty Solution it is THE solution. You will never be allowed to go back and fix it unless it is hideously broken, in which case you are in trouble anyway.
So, you have to look at the amount of money you expect to earn from this client/LoB, both short-term and long-term, your current and desired respect level from same, and the amount of political pull you have from accompanying lines of business. If you're under a lot of pressure from management to deliver a Q&D solution, with enough political power and respect, you may be able to pull out a better solution.
Cover your butt. Emails, phrased in a friendly way, just mentioning potential problems, can go a long way to helping smooth things over when things go to hell. Read about managing people.
Now, the more overarching answer is that the quick and dirty solution is almost never the real solution, unless your idea of quick and dirty differs vastly from mine. It's just not the right way to do business, and will inevitably end up costing you and your customer more money in the long-term, and heaven help you if your customer figures it out.
I work for a company that's building a product, and while we're under deadlines just like everyone else, we simply draw a line in the sand about what features won't be implemented rather than half-assing the ones we do. And just like everything else, its a tug of war between the people building it and the people selling it.
The upshot of all this is that you have to manage the expectations of those that are in control. You have to say what will and won't be implemented, what corners you're cutting, and what the possible implications of those things are. It becomes far more about managing and dealing with people than building technology. I bet in your organization there are managers that somehow consistently manage to get their way - watch what they do, whether its simply presenting problems a certain way or they play golf with the boss - it could be anything. Learn from watching them how to manage the people that create barriers to your building a proper solution.
Thanks,
Matt
--
http://www.gridapp.com
You might want to look for Netapp FC(xx) disk shelves. They're normal hot-swap fibre channel JBODs. They're also very expensive, but if you get lucky you might see one sans drives and get it for much cheaper.
Thanks,
Matt
I'm questionable on whether this is on-topic, but it seems relevant. My company, a startup in NYC, is looking for a college-level intern to work with us on developing our software and building our our infrastructure. Here's some of the stuff we work with:
-Linux
-Oracle and a bit of SQL Server
-Cisco
-C, Perl, C++, Java, a bit of ASP
While we can't offer money (we're a startup, after all), here's what we can offer you:
-A letter of recommendation. (we write well).
-A chance to actually complete significant projects with assistance from the rest of us. This won't be simply making cables and fetching coffee (though there will probably be some cable making).
-The opportunity to work with an extremely talented group of individuals who have built several very large-scale systems and application infrastructures.
If you live in the NYC area and are interested, send me an email, and I'll give you more details.
Thanks much,
Matthew Zito
Availability checks for domain name registrars never hit the root servers. The registrars connect directly to the SRS (Shared Registry System) and look up records there.
.com, .net, and .org), none of them refresh in real-time, so you could be registering a domain that had actually been taken 6 hours previously.
It would be silly to use the root servers as a basis for availability, especially since the root servers know nothing about individual domains, only TLDs (the root server zone file is less then 50k, iirc) . But even assuming you meant the DNS servers one level down(like the GTLD servers that handle
Thanks,
Matt
It's a fundamental bridge between two different worlds - the PSTN and IP networking. The real utility of this is not so much the one-id-for-every-contact, its things like pstn->ip telephony->pstn. Some of the applications include:
-Combining with SIP to provide global number portability - no cell phone roaming overseas, etc.
-Reducing international tariff burdens by terminating calls in countries with better tariff agreements with the destination (i.e. it is much cheaper for the UK to call France than for the US to call France, so you route the call over IP to the UK, then go PSTN from the UK to France).
-Simplifying carrier-transit agreements
And these are just the ones we've come up with so far. It's worth noting as well that part of the ENUM spec is the use of a new dns record type - NAPTR, which allows regular expression functionality in DNS RRs...the mind reels at the possibilities.
For the people who want to know about e164.arpa, that is planned to be the global TLD for ENUM. Thanks to the miracle of DNS delegation, each country code can be administered by the country itself. The only one that's really complicated is the US, since it includes other countries in the +1 country code.
The problems with ENUM are primarily that most of the phone companies have solved some of these problems with proprietary (generally inferior) solutions. They're slow-moving to begin with and don't immediately see the utility in implementing ENUM. It's mostly up-and-coming CLECs and VoIP companies that are looking to ENUM to both generate revenue and save money.
Plus, there is already enum support in a variety of products. Cisco's VoIP suite includes ENUM support (only the SIP line, not the H.323), so you could roll out ENUM within your organization. I have a feeling that ENUM will be much like BGP or DNS is today - 95%+ of the population will either use or benefit from it, and never be aware of its existence.
Thanks,
Matt
We won't see open blade servers for quite a while, if ever. Normal servers are only "open" because they use a common set of interconnects (standard power, ps/2 keyboard, 100BaseT), etc. On a blade server, you have to unify all of those interconnects in a hot-swappable fashion. The result? A customized connector and backplane architecture.
In addition, there's no incentive for companies to open a standard for blade servers - they'll make more money by selling the chassis and blades, as well as the management software that is generally required for these types of servers.
As far as Google goes, they rolled out their infrastructure for such a low cost because they did the following things:
1) didn't use blade servers(more on that in a sec)
2) bought in large quantities
3) bought generic/semi-generic servers (by which I mean "not IBM")
Not using blade servers was a sharp idea because the real advantages of blade servers come in certain particular situations. These include where power/heat/space is really expensive or where you need a lot of hosts without a lot of performance (like QA, staging and development environments). Remember, that while they use less space, power, etc., they also use laptop/low-power cpus and hard drives, so the performance can be lower, especially for i/o intensive operations. If you're not hugely space-constrained, using 1U servers will save you money in the long run.
Thanks,
Matt
Hey, just because I've got a crackpot idea doesn't mean its not true. :)
Thanks,
Matt
"Using databases to manage concurrency (and a whole lot of other things) greatly simplifies projects IMO"
This is only partially true, and the "partially" derives from the scale the application is being built on. It's very possible to realize development time savings by whacking your mp3 playlist information into mysql rather than parsing out data yourself - but that won't work quite as well when you're indexing 30,000,000 mp3s.
Using a database will make WRITING your application easier - but the job is not done when QA gives it the green light. That application has to be maintained, either by you, or by the customer (and since we're talking about J2EE server applications, we'll presume its by you).
Databases are expensive, not just in the cost of the software/hardware, but in the cost to manage them. The whole model of tightly coupling data together in one place is what allows you to realize development savings ("Rather than write an efficient Java function to find every person who lives in the specified state in the same zip code, I'm going to let the database figure it out with two lines of SQL!!") - coupling, though, also forces you to have big databases - you won't get any benefit if your data is spread across farms of different servers. When I'm referring to databases, btw, I mean OLTP-style databases, as it is very rarely acceptable for web applications to have data warehouse-equivalent delays in data retrieval.
As your database increases in size and complexity, the cost to operate it increases EXPONENTIALLY. So, while dedicating a 2-processor linux box to database traffic is highly cost effective (say $2000), the cost of dedicating a 10-processor, 64-bit Sun box to database traffic is not (market price $100k-200k depending on new vs. reman, discount structure, etc.). Likewise, software and storage costs grow in a similar fashion - two 36GB scsi disks will cost you a few hundred dollars, while a 3.6TB enterprise storage array will cost you in the hundreds of thousands of dollars. Management costs as well begin to come into play - it takes a very different skill set to run a 2GB database from a 2TB database.
If you expect your application to grow exponentially, relying on a database will make your costs grow exponentially as well.
The right way is to only put long-term, persistent data in your database. Nothing transient should ever hit your database, ever. Even old and unused persistent data should be periodically dumped out to tape or to a data warehouse and purged from your production database. Scale horizontally, not vertically. Put yourself in a situation where when your site gets slow, you need to buy another 5 linux web/application servers, not forklift upgrade your 4-processor database to an 8-processor database.
This fundamental flaw in the all-in-the-database system is why companies like Oracle have invested millions of dollars in allowing their software to scale horizontally - in effect, to get the best of both worlds. But, you still have the management problems associated with large centralized storage, backups, plus licensing costs, etc.
None of this is to say that centralizing business intelligence in a database is always a bad idea. But I have worked in situations where people put intelligence in the database with the best intentions, only to discover themselves victims of their own success. Look at google for possibly the ultimate example of de-centralization. They do nothing BUT scale horizontally, and while that isn't necessarily the answer either, it shows it can be done.
Here's what you have to ask yourself as you write any serious, enterprise-grade application:
1) As my data grows, does my revenue grow exponentially (or even linearly) with it?
2) How long does this data need to persist?
3) How can I group my data in such a way that groups can be completely uncoupled from each other within the database as my environment grows?
4) How can I accomplish my purpose without touching the database?
Of those, 1) is the longest term - very rarely does revenue grow at the same pace as data, so the cost of data storage has to be kept down. 2) and 3) is pure practicality - never store anything that you don't plan to eventually delete, and 4) is getting yourself into the mindset that the OLTP database is the location of last resort for data.
Phew. I've been wanting to get that off my chest for a while.
Thanks,
Matt
I'm afraid you're extremely misinformed. Internic did not become register.com....it was always Network Solutions, which was acquired by Verisign. Register.com is a competitive registrar in its own right (the first competitive registrar ever, incidentally).
In addition, ICANN has nothing to do with the domain name related spam you receive. In fact, the WHOIS agreements ICANN requires explicitly forbids the use of Whois data for commercial email purposes.
In addition, the beauty of our DNS architecture as it stands today is that whatever protocols we want can develop and be completely uninvoved with ICANN. All ICANN has to do with DNS is their operation of the roots, which means a small number of NS records delegating to the TLD servers. It would be extremely difficult for them to do something really evil with them.
Thanks,
Matt
There are a number of companies that make equipment to handle this type of situation - NCipher is the only one I'm familiar with specifically (I've never used it - just evaluated it).
Basically its a PCI card, or a little box with a SCSI connector on it (don't ask), that you plug in/hook up to your server. The card/server can then store keys internally and perform operations on data passed in & out of it. So, generate a key, store it on the card/box, write your app to pass CC info to the card library, statically link the library into the application and then erase the library.
To protect the information from physical tampering, the card and the box implement FIPS-grade protection. The card is level 2 (iirc) - the chips that store the data have a big thick black cover on them. Should you tear that off, it creates a chemical reaction that destroys the chips and their data. The box can be FIPS level 3, which means if you pick it up or otherwise shake it, the keys are destroyed.
Key escrow is handled by built-in smartcard readers, and you can do secret sharing (i.e. requiring two-of-five people to insert their smartcards to load the key).
It's not cheap - the lowest-end model is 11k, as I recall, but it gives you what you need. It's a secure mechanism for maintaining secret data.
For an extra level of paranoia, use LIDS or Argus Trusted Solaris, and use ACLs to only grant your application permission to access the device files for the key storage. That way, even if someone wrote an app and linked it against the key management lib, they can't get at the device instance to do anything.
Just depends on how much you're willing to pay and go through (hassle-wise) to get real security.
Thanks,
Matt
An old friend of mine who worked for an ISP that shall remain nameless was one of the engineers working on the webcast of a Very Large Event (tm). They needed to deploy all of the architecture, etc. needed to broadcast the video to thousands and thousands of people worldwide, and they were under a tight deadline.
So, there were a multitude of servers, network gear, cables, etc. that all were shipped to the location. Most of it made it there okay. But a rather key piece - a multi-hundred-thousand-dollar Cisco 7513 that was to serve as the core router for the whole infrastructure, never made it to its destination. The shipping company sort of shrugged and apologized, but that still left the problem of how to get a new 7513 to the location in time.
Cisco was very helpful - promptly delivering a new 7513 on rush, but it was delivered to the ISPs offices. They opted not to trust it to the vagaries of shipping, and instead put someone on a plane, and checked the crated router as "critical cargo", supposedly the highest level of service an airline will give.
Well, they lost it.
It got put on a cargo plane to somewhere remote, and wouldn't be back for days. The people at the ISP were frantic. They needed a router RIGHT NOW, something they could get over there, and they needed some transport mechanism that would be foolproof.
So, they pulled a standby 7513 out of production, scraped together the needed linecards, put it on a handtruck, and drove it to the airport. Once there, they bought the escorting engineer two plane tickets - one for the engineer.........and one for the router. Of course, a 7513 is too big for coach seats, so they put the both of them right next to each other......in first-class.
History does not record whether the router had the chicken or the fish.
But, the router made it there, probably having enjoyed the in-flight movies and complimentary steamed towels, and cheerfully fulfilled its duty , pushing packets to and fro.
And then it was shipped back UPS ground, probably dreaming of its taste of the high life.
Matt
The holdup on IDN is based in the IETF - the protocol standard for IDN has not yet been finalized, although chances are good it will be at the next IETF in a few weeks. It would be premature and equally bad for ICANN to declare a standard outside of the scope of the IETF, where standards are supposed to be made.
And while Mara and Djbdns may support UTF-8 encoding within the DNS, as far as I know, that is not the IETF's proposed standard solution.
Thanks,
Matt
A better reason is that ICANN wants to demonstrate that it wants to be representative of the whole world. If they meet only in the US and EU, then they're Euro-centric, but then they meet outside of the US, and they're trying to party it up in Africa....can't have it both ways.
Also, one of the heads of the steering committee (I think - one of the heads of ICANN, anyway) is from Ghana.
Thanks,
Matt
I bought one of these and promptly traded it for an Ipod as soon as it was available.
.02,
The interface is good, the size is downright tiny, but the battery life is miserable. Perhaps the reviewer was using the 1GB microdrive, which actually has a lower RPM than the 340MB (which is what I'm using) and consequently gets a better battery life, but my NexII would last a max of 3 hours on 2 batteries.
Not only that, but when the battery starts to get low, the nex II experienced lockups and crashes. It was an extremely frustrating experience. All of this only applied to the microdrive - with a CF card, it worked great. But the whole reason I purchased it was for its microdrive support. I did everything their manuals and website suggested, but it didn't really help.
Oh, and another annoying thing - the "shuffle" feature will always sort the songs in the same order.
Just my
Matt
That's different - namezero gives you the name for FREE, only they retain ownership.
Thanks,
Matt
How can anyone verify the veracity of this without the domain name? I could type that up just as easily as you could. If you post the name, perhaps we can get to the bottom of this. At the very least, email it to me.
Thanks,
Matt
I've never heard this. Please cite evidence to support your claim.
Thanks,
Matt
No way - if you're a large organization with a couple of thousand domain names, it costs you maybe 20 dollars a year per name to keep them. What's 50k to a huge corporation?
Thanks,
Matt
Well, it was a joke - but yes, it does use 83 as its partition type.
Matt