Unfortunately, enterprises tend to pre-purchase shared storage and buying 8TB of disk when you only need 1TB of space tends to get you noticed during economic downturns.
There will always be a market need for small, fast drives, and to bring this back to the original guy's point - it's because by some very practical considerations, several performance metrics per raw TB have actually declined.
That may be so. The new drive may indeed have four times the raw read throughput. But how much larger are they? Five times.
And even more tellingly, look at the seek performance. I looked up those two drives you mentioned. You'll find it's unchanged at 8.5ms. So we're seeking at the same speed, for more data.
In practice, then, in terms of throughput per provisioned GB, we are 24% worse off, and in terms of seek time per megabyte we are TEN times worse off today!
To illustrate what I mean, based on those numbers above: slurping 10TB off an idealised JBOD array of those newer drives would take 89 seconds; slurping 10TB off an idealised array of the older drives in parallel would take only 72 seconds. A similar (but far worse) story applies to random seek time performance, especially for busy transaction systems.
One might challenge the exact figures, but it doesn't matter - the point is, drive size is an important gotcha in storage performance optimisation today, and it's because performance has not really kept pace with drive size. The issue is not offset by the bigger caches they're turning up with, although that helps for some workloads.
We haven't talked dollars. The cost is important, but that's another dimension. Let's keep this to engineering chatter.
So what happens in shops that need really high performance? Well, if it's an application with lots of random reads but with hotspots, then cache will do nicely. But for raw random write performance i.e. the heavy transaction processing applications, it's gotta be more 15K RPM spindles at lower capacity. Or go crazy and solid state, but that's another party.
Privacy is not important and it's a myth that you ever had it. Your identity is not important. If it gets stolen, you can make a new one. In the meantime, you're just being another antisocial geek who didn't learn the value of networking.
The problem is, Perl is just a programming language, not a conceptual system. Arguably it is the antithesis of a conceptual system. Many teams then create their own application frameworks atop it (e.g. Mason, POE), and it's rare for these frameworks to be compatible since Perl offers so many variations in the construction of even standard programming artifacts like classes & objects.
In addition, the level of expression (i.e. TMTOWTDI) means in practice that highly varying programming styles occur throughout large, long-lived bodies of code.
As a result, significant Perl-based business applications tend to become hard-to-maintain hairballs of divergent style and subtly variegated concept.
The root cause: as I started with; the absence of a standard conceptual framework for Perl means that during the early phases of a project, it's much harder to reason meaningfully about the eventual form of the system than it is with, say, Java or.NET where many of the design patterns are explicitly standardised.
I wouldn't say that "Corporates Hate Perl". It's just the Perl as an application language doesn't suit the formal design & architecture process we're seeing increasingly as IT departments start to grow up and realise that they're not the most important people in the company.
That doesn't disqualify Perl from being a useful tool, and it'll always have a place in data transformation, but it does mean that Perl isn't going to be one of the general-purpose application programming languages of the future.
This is a stumbling block on Apple's road to the enterprise. That's out of alignment with the technology plan for Snow Leopard server, which includes many new features directly aimed at supporting the mid-sized enterprise.
Combine that with the general trend towards browser-as-client, and with the advent of VMware Fusion and Parallels, and at a time when there's no compelling case to deploy Vista during a desktop refresh. Apple have significant position to attack the enterprise desktop & backend.
However: transparency, rapid response, and disclosure rule the day with competent corporate security teams and this kind of a malarky just won't wash with my guys.
Have a little imagination. You don't need root/enable to make a difference. In fact, stepping back from it, and working solely through others, should give you a new perspective on what's important.
If you're moving on to establish an entire department, then that's a very good thing; departmental chiefs that get bogged down in details are not only misusing their time, they're stealing opportunity from those just getting started.
The RIPE NCC's Special Projects group have been offering sub-microsecond latency/jitter/analytical services to ISPs for years. Their data is invaluable and unique, since it measures latency, jitter and packetloss in a single direction (unlike ICMP Ping, which is a round-trip measurement over an asymmetric path) and goes back at least to 2000. The paper claims accuracy to 0.0006 ms, which was good for the time when the product was designed.
I guarantee that if you call yourself a guild, you're not the oldest.
What's all the fuss anyway? I've been in online multiplayer gaming organisations for twenty years. Two of them are still going after all that time.
This book sounds like self-aggrandizing tosh.
Is *is* as simple as a database query, but generally the Game Masters in a MMO would not have the ability to issue arbitrary queries to the game servers / engines.
Nonetheless it is pretty normal for them to be able to instantly jump to the location of a named character. If it was a problem for an unusual character, that's most likely a bug or game artefact preventing them doing so. Or they didn't know its name.
That'd all require an escalation to a higher level, perhaps even to a DBA, which depending on the severity of the issue they might be disinclined to do.
I recently designed and built a mail system for a six-digit ISP userbase.
Before I feed you the design, let me tell you a *crucial* concept that you must carry with you at all times.
EMAIL SYSTEMS ARE PROTOCOL SPEAKERS BETWEEN USER DIRECTORIES AND STORAGE.
Read that and inwardly digest it before you even start to design your system.
For the design, first, I'm going to proselytize a particular piece of software.
DOVECOT IS THE FREE POP/IMAP SERVER OF THE FUTURE. It leaves the Cyrus codebase rotting in the slime. It already kicks Courier's butt in performance and ease of deployment. It's beautifully coded; it has the most elegant authentication architecture; it's exceptionally fast. It isn't complete yet but it's featureful and stable enough that I have successfully deployed 1.0-betas into production. http://www.dovecot.org/ for the last IMAP server you'll ever need.
Here is the design:
1 x OpenLDAP 2.3 master server 2 x OpenLDAP 2.3 read-only replicas 2 x world-facing mail servers running Postfix 2.3 4 x mail scanning servers running amavisd-new 2.3.3, ClamAV, SpamAssassin, Sophos SAVI and Sophos PMX-ENGINE. LMTP in from the mail front-ends; ESMTP out to the mail storage. 2 x mail storage front-ends running Postfix 2.3 and Dovecot IMAP/POP3 1.0-beta. These servers also run mysql for amavisd-new quarantine and squirrelmail user options. Actual storage is over NFS to the NetApps. Using Dovecot's Sieve-based delivery agent for server-side filtering. 2 x Squirrelmail webmail servers. We have our own skin, and our own sqm plugins as the user interface to our various system options - which are all in LDAP. We have integrated MailZu into sqm as a quarantine view/release interface. 2 x NetApp FAS3020c heads w/4TB NFS storage allocated to mail.
Everything is load-balanced using foundry hardware LBs. It's very high-throughput and very reliable. It's also easy to monitor (we're using Nagios).
Base OS is Debian Sarge with applicable backports. I'd prefer FreeBSD but this happens to be a Debian shop, and I wasn't out to change their world, just their mail system.
Probably the most borderline item is mysql's performance as a quarantine DB; however much RAM and index/query tuning we throw at it, I'm yet to be satisfied with InnoDB's performance on this 100GB+ INSERT-heavy database.
If I could change one thing about it, it'd be to use the extremely pretty and surprisingly good value @mail (a commercial choice) rather than SquirrelMail. I'd also consider Fedora Directory Server over OpenLDAP, but it wasn't looking ready for this design at the time.
I have to say there is some bad advice in this thread; now for the hatchet:
Cyrus: difficult to configure, doesn't support shared storage, horribly ugly codebase, and has some nasty-ass failure modes. Qmail: stale, poorly integrated MTA software from the bitchiest developer in town. Sendmail: doesn't scale. Even the developers think so, which is why Sendmail X is a rip-off of postfix. Communigate Pro: if I don't get to futz with the source for integration and value-add, I'm not interested. GFS/GPFS: you don't need the complexity or interesting failure modes of shared-block-storage filesystems. Stay away. Linux NFS: isn't reliable enough. We've had problems with data corruption to Linux NFS, both kernel and userland. Right now the only NFS server implementations I trust are NetApp's and Solaris's. No doubt the Linux one can/will improve, or already has, but trust is a hard thing to build:). Plus NetApps are shiny, marvelously reliable, and I love their support.
Sounds like a classic Cisco problem. I don't know what switches LJ were plugged into, but for years most Cisco switches would autonegotiate 100/half-duplex if the NIC was locked to 100/full; conversely, sometimes, NICs would autonegotiate 100/half if the Cisco was locked to 100/full.
They're cheeky enough to document this now. It's a feature, not a bug! Honest!
I get unsolicited mail from people impressed by it, and asking if they can use the same format. Feel free (I retain all rights to the text, of course).
I also just got a new job, so I'm doing something right (although it could be despite the CV, heh).
My CV guidelines:
Fixed size of four pages.
Use clear English in text passages.
Use a clean, professional format that looks good on screen and paper.
Start with Career Objective, since it demonstrates motivation and bundles the career history together.
Follow with the skill checklist, which is all that some recruitment people will look at anyway.
Follow with the employment history, most recent at the top with the most detail. Every time I've moved job, I've compressed the wording for older entries.
Successes are interesting. Highlight them in a way that entices discussion at interview. Corollary: you must be able to discuss absolutely everything mentioned in your resume, in depth and detail.
I don't bother with an education section. At my career stage, it's irrelevant. I'm not interested in working for people who think it is.
Keep the miscellaneous section to a single page.
Original is HTML, revision-controlled. I prefer to send the PDF version when submitting applications, because it guarantees format, and because I've known recruiters to deliberately edit Word format etc without my authorization.
This tool reports to MS when it cleans. The reporting is anonymous, it says in the EULA.
Those of you who detest automatic vendor notifications can disable this function. I just followed a tortuous string of buried references from MS to find out how, so to save you all the hassle, here's the thing:
Using regedit, create registry key HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\MRT \DontReportInfectionInformation as a DWORD, and set the value to 1.
Re:Maintainance nightmare
on
Decompiling Java
·
· Score: 5, Insightful
I'm sure he's talking about obfuscating the bytecode, not the source code.
This project bills itself as a means to "deploy disruptive technologies" in the Internet. Unfortunately, it doesn't achieve that. Quite the opposite; it isolates those disruptive technologies as islands of functionality, and thereby isolates itself.
This has been tried before with IPv6 and Multicast, to name two enabling technologies that after years of standards development and experimental rollout still have yet to achieve global acceptance.
Although the distributed, virtualized service approach is itself a worthy direction of research, it doesn't replace existing protocols and it doesn't even begin to address the pressures that actually keep existing technologies in place, that is, the economic ones of traffic exchange and mass appeal.
The thing that really dooms this project, apart from the focus on technical solutions to economic issues, is its reliance, apparently (from my reading of their technical documents) on Red Hat Linux as a virtualization platform, and the deliberate tie to virtual server technologies.
My predicted likelihood of this particular project replacing IPv4 and existing protocols as a communications technology platform: nil.
Finally, a tip for the authors of PlanetLab technical documents: please stop slapping the annoying word DRAFT in diagonal 200pt 50% grey across every page. It's not a draft if you've left it published untouched for two years. If you need to indicate that This Is Not Set In Stone, put words to that effect in the title of the paper.
> "How would you distribute root over hundreds of Unix machines to the administrators that need it?"
We have a similar team size and a similar number of servers. In addition there are other teams with access to more limited (regular user) team role logins. Access also varies according to server role and location.
These systems are often located in continents away in untrusted locations. So passwords are not acceptable.
My solution:
We have a standard Debian package that updates/etc/ssh/authorized_keys/{login} using an access control list that we distribute to every box. The control file is centrally managed (kept in CVS) and has groupings for roles, individuals and servers, so administration is a breeze. The generator is just a short perl script. Finally, we have these lines in/etc/ssh/sshd_config:
We make a contingency for emergencies, but I won't describe it here. Suffice to say that it's safe enough to use, analysed enough that it's not snake-oil, and inconvenient enough to stop sysadmins in a hurry from using it by default:)
1. The waiter has practically no career path to follow. The higher base pay you perceive is partial compensation for this fact. A waiter's salary will not quadruple over the coming decade. They will not become the chef, nor will he likely get to manage the restaurant.
2. My current role includes interviewing developers and making hiring recommendations. Our finding is always that a CompSci degree does not qualify you for a software engineering job. Although some of our developers have a CompSci background, none of them use it in day-to-day work. The mindset and skillset of a software engineer is quite different.
Slashdot Mirror
Unfortunately, enterprises tend to pre-purchase shared storage and buying 8TB of disk when you only need 1TB of space tends to get you noticed during economic downturns.
There will always be a market need for small, fast drives, and to bring this back to the original guy's point - it's because by some very practical considerations, several performance metrics per raw TB have actually declined.
That may be so. The new drive may indeed have four times the raw read throughput. But how much larger are they? Five times.
And even more tellingly, look at the seek performance. I looked up those two drives you mentioned. You'll find it's unchanged at 8.5ms. So we're seeking at the same speed, for more data.
In practice, then, in terms of throughput per provisioned GB, we are 24% worse off, and in terms of seek time per megabyte we are TEN times worse off today!
To illustrate what I mean, based on those numbers above: slurping 10TB off an idealised JBOD array of those newer drives would take 89 seconds; slurping 10TB off an idealised array of the older drives in parallel would take only 72 seconds. A similar (but far worse) story applies to random seek time performance, especially for busy transaction systems.
One might challenge the exact figures, but it doesn't matter - the point is, drive size is an important gotcha in storage performance optimisation today, and it's because performance has not really kept pace with drive size. The issue is not offset by the bigger caches they're turning up with, although that helps for some workloads.
We haven't talked dollars. The cost is important, but that's another dimension. Let's keep this to engineering chatter.
So what happens in shops that need really high performance? Well, if it's an application with lots of random reads but with hotspots, then cache will do nicely. But for raw random write performance i.e. the heavy transaction processing applications, it's gotta be more 15K RPM spindles at lower capacity. Or go crazy and solid state, but that's another party.
PALO ALTO (Reuters). PHP-based website reports scalability problems. Blames server hardware. Film at 11.
Privacy is not important and it's a myth that you ever had it. Your identity is not important. If it gets stolen, you can make a new one. In the meantime, you're just being another antisocial geek who didn't learn the value of networking.
The problem is, Perl is just a programming language, not a conceptual system. Arguably it is the antithesis of a conceptual system. Many teams then create their own application frameworks atop it (e.g. Mason, POE), and it's rare for these frameworks to be compatible since Perl offers so many variations in the construction of even standard programming artifacts like classes & objects.
In addition, the level of expression (i.e. TMTOWTDI) means in practice that highly varying programming styles occur throughout large, long-lived bodies of code.
As a result, significant Perl-based business applications tend to become hard-to-maintain hairballs of divergent style and subtly variegated concept.
The root cause: as I started with; the absence of a standard conceptual framework for Perl means that during the early phases of a project, it's much harder to reason meaningfully about the eventual form of the system than it is with, say, Java or .NET where many of the design patterns are explicitly standardised.
I wouldn't say that "Corporates Hate Perl". It's just the Perl as an application language doesn't suit the formal design & architecture process we're seeing increasingly as IT departments start to grow up and realise that they're not the most important people in the company.
That doesn't disqualify Perl from being a useful tool, and it'll always have a place in data transformation, but it does mean that Perl isn't going to be one of the general-purpose application programming languages of the future.
This is a stumbling block on Apple's road to the enterprise. That's out of alignment with the technology plan for Snow Leopard server, which includes many new features directly aimed at supporting the mid-sized enterprise.
Combine that with the general trend towards browser-as-client, and with the advent of VMware Fusion and Parallels, and at a time when there's no compelling case to deploy Vista during a desktop refresh. Apple have significant position to attack the enterprise desktop & backend.
However: transparency, rapid response, and disclosure rule the day with competent corporate security teams and this kind of a malarky just won't wash with my guys.
Have a little imagination. You don't need root/enable to make a difference. In fact, stepping back from it, and working solely through others, should give you a new perspective on what's important. If you're moving on to establish an entire department, then that's a very good thing; departmental chiefs that get bogged down in details are not only misusing their time, they're stealing opportunity from those just getting started.
The RIPE NCC's Special Projects group have been offering sub-microsecond latency/jitter/analytical services to ISPs for years. Their data is invaluable and unique, since it measures latency, jitter and packetloss in a single direction (unlike ICMP Ping, which is a round-trip measurement over an asymmetric path) and goes back at least to 2000. The paper claims accuracy to 0.0006 ms, which was good for the time when the product was designed.
Read about the project here and the paper on TTM [pdf] that was presented at the PAM2001 conference.
(This isn't what Corvil do.)
I guarantee that if you call yourself a guild, you're not the oldest. What's all the fuss anyway? I've been in online multiplayer gaming organisations for twenty years. Two of them are still going after all that time. This book sounds like self-aggrandizing tosh.
Is *is* as simple as a database query, but generally the Game Masters in a MMO would not have the ability to issue arbitrary queries to the game servers / engines.
Nonetheless it is pretty normal for them to be able to instantly jump to the location of a named character. If it was a problem for an unusual character, that's most likely a bug or game artefact preventing them doing so. Or they didn't know its name.
That'd all require an escalation to a higher level, perhaps even to a DBA, which depending on the severity of the issue they might be disinclined to do.
That sounds like regular play in Eve, not griefing.
They don't want more subscribers like you. They make the game they want to play, they don't design it for the largest possible market.
That bullshit direction of marketing-focus-group driven design is the reason I don't play WoW.
I recently designed and built a mail system for a six-digit ISP userbase.
:). Plus NetApps are shiny, marvelously reliable, and I love their support.
Before I feed you the design, let me tell you a *crucial* concept that you must carry with you at all times.
EMAIL SYSTEMS ARE PROTOCOL SPEAKERS BETWEEN USER DIRECTORIES AND STORAGE.
Read that and inwardly digest it before you even start to design your system.
For the design, first, I'm going to proselytize a particular piece of software.
DOVECOT IS THE FREE POP/IMAP SERVER OF THE FUTURE. It leaves the Cyrus codebase rotting in the slime. It already kicks Courier's butt in performance and ease of deployment. It's beautifully coded; it has the most elegant authentication architecture; it's exceptionally fast. It isn't complete yet but it's featureful and stable enough that I have successfully deployed 1.0-betas into production. http://www.dovecot.org/ for the last IMAP server you'll ever need.
Here is the design:
1 x OpenLDAP 2.3 master server
2 x OpenLDAP 2.3 read-only replicas
2 x world-facing mail servers running Postfix 2.3
4 x mail scanning servers running amavisd-new 2.3.3, ClamAV, SpamAssassin, Sophos SAVI and Sophos PMX-ENGINE. LMTP in from the mail front-ends; ESMTP out to the mail storage.
2 x mail storage front-ends running Postfix 2.3 and Dovecot IMAP/POP3 1.0-beta. These servers also run mysql for amavisd-new quarantine and squirrelmail user options. Actual storage is over NFS to the NetApps. Using Dovecot's Sieve-based delivery agent for server-side filtering.
2 x Squirrelmail webmail servers. We have our own skin, and our own sqm plugins as the user interface to our various system options - which are all in LDAP. We have integrated MailZu into sqm as a quarantine view/release interface.
2 x NetApp FAS3020c heads w/4TB NFS storage allocated to mail.
Everything is load-balanced using foundry hardware LBs. It's very high-throughput and very reliable. It's also easy to monitor (we're using Nagios).
Base OS is Debian Sarge with applicable backports. I'd prefer FreeBSD but this happens to be a Debian shop, and I wasn't out to change their world, just their mail system.
Probably the most borderline item is mysql's performance as a quarantine DB; however much RAM and index/query tuning we throw at it, I'm yet to be satisfied with InnoDB's performance on this 100GB+ INSERT-heavy database.
If I could change one thing about it, it'd be to use the extremely pretty and surprisingly good value @mail (a commercial choice) rather than SquirrelMail. I'd also consider Fedora Directory Server over OpenLDAP, but it wasn't looking ready for this design at the time.
I have to say there is some bad advice in this thread; now for the hatchet:
Cyrus: difficult to configure, doesn't support shared storage, horribly ugly codebase, and has some nasty-ass failure modes.
Qmail: stale, poorly integrated MTA software from the bitchiest developer in town.
Sendmail: doesn't scale. Even the developers think so, which is why Sendmail X is a rip-off of postfix.
Communigate Pro: if I don't get to futz with the source for integration and value-add, I'm not interested.
GFS/GPFS: you don't need the complexity or interesting failure modes of shared-block-storage filesystems. Stay away.
Linux NFS: isn't reliable enough. We've had problems with data corruption to Linux NFS, both kernel and userland. Right now the only NFS server implementations I trust are NetApp's and Solaris's. No doubt the Linux one can/will improve, or already has, but trust is a hard thing to build
Sounds like a classic Cisco problem. I don't know what switches LJ were plugged into, but for years most Cisco switches would autonegotiate 100/half-duplex if the NIC was locked to 100/full; conversely, sometimes, NICs would autonegotiate 100/half if the Cisco was locked to 100/full.
They're cheeky enough to document this now. It's a feature, not a bug! Honest!
Ok, I'll bite. Here's mine: HTML primary version or PDF edition.
I get unsolicited mail from people impressed by it, and asking if they can use the same format. Feel free (I retain all rights to the text, of course).
I also just got a new job, so I'm doing something right (although it could be despite the CV, heh).
My CV guidelines:
This tool reports to MS when it cleans. The reporting is anonymous, it says in the EULA.
T \DontReportInfectionInformation as a DWORD, and set the value to 1.
Those of you who detest automatic vendor notifications can disable this function. I just followed a tortuous string of buried references from MS to find out how, so to save you all the hassle, here's the thing:
Using regedit, create registry key HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\MR
I'm sure he's talking about obfuscating the bytecode, not the source code.
RTFM.
ps -U
Technically, this is a Trojan Horse, not a virus.
I do all of that, but I do it on FreeBSD. What made you think that level of flexibility is limited to Linux?
This project bills itself as a means to "deploy disruptive technologies" in the Internet. Unfortunately, it doesn't achieve that. Quite the opposite; it isolates those disruptive technologies as islands of functionality, and thereby isolates itself.
This has been tried before with IPv6 and Multicast, to name two enabling technologies that after years of standards development and experimental rollout still have yet to achieve global acceptance.
Although the distributed, virtualized service approach is itself a worthy direction of research, it doesn't replace existing protocols and it doesn't even begin to address the pressures that actually keep existing technologies in place, that is, the economic ones of traffic exchange and mass appeal.
The thing that really dooms this project, apart from the focus on technical solutions to economic issues, is its reliance, apparently (from my reading of their technical documents) on Red Hat Linux as a virtualization platform, and the deliberate tie to virtual server technologies.
My predicted likelihood of this particular project replacing IPv4 and existing protocols as a communications technology platform: nil.
Finally, a tip for the authors of PlanetLab technical documents: please stop slapping the annoying word DRAFT in diagonal 200pt 50% grey across every page. It's not a draft if you've left it published untouched for two years. If you need to indicate that This Is Not Set In Stone, put words to that effect in the title of the paper.
Official, Sun-approved BSD Java is available right now.
I have odor reconstruction hardware, but people always send me .wif files!
Unfortunately it accepts only compressed Nosepeg.
If your contingency plan is so perfect, why are you afraid to describe it publicly?
- I said it was sufficient, not perfect.
- It's not relevant to the question.
- It's left as an exercise for the reader.
- Joshua.> "How would you distribute root over hundreds of Unix machines to the administrators that need it?"
/etc/ssh/authorized_keys/{login} using an access control list that we distribute to every box. The control file is centrally managed (kept in CVS) and has groupings for roles, individuals and servers, so administration is a breeze. The generator is just a short perl script. Finally, we have these lines in /etc/ssh/sshd_config:
/etc/ssh/authorized_keys/%u
:)
We have a similar team size and a similar number of servers. In addition there are other teams with access to more limited (regular user) team role logins. Access also varies according to server role and location.
These systems are often located in continents away in untrusted locations. So passwords are not acceptable.
My solution:
We have a standard Debian package that updates
AuthorizedKeysFile
PermitRootLogin without-password
We make a contingency for emergencies, but I won't describe it here. Suffice to say that it's safe enough to use, analysed enough that it's not snake-oil, and inconvenient enough to stop sysadmins in a hurry from using it by default
- J
Two points:
1. The waiter has practically no career path to follow. The higher base pay you perceive is partial compensation for this fact. A waiter's salary will not quadruple over the coming decade. They will not become the chef, nor will he likely get to manage the restaurant.
2. My current role includes interviewing developers and making hiring recommendations. Our finding is always that a CompSci degree does not qualify you for a software engineering job. Although some of our developers have a CompSci background, none of them use it in day-to-day work. The mindset and skillset of a software engineer is quite different.