The really ideal solution would be a p2p backup network. Each client has their own encryption keys, and agrees that for every X kbytes of local data they need backed up, they're willing to store 3X worth of data from others. Your data is encrypted with your key before being sent out to the p2p network, which is designed to keep a minimum of 3 remote copies of your data out there - if less than 3 copies are detected for any decent amount of time, it just makes more copies on other machines. When you need your data, all you need is your key (it's on a USB drive and/or floppy, or whatever) to decrypt the copies you pull from the p2p backup service.
Sun has not been selling multicore UltraSparcs at all, unless they started within the past 4 months or so. They may have been claiming they exist, but they aren't for sale (I haven't looked in 4 months or so, could be now - but not 1-2 years like you claim).
I wasn't attacking POWER or PA-RISC, only Sun, so there was no need for the rest of your crap, and I won't respond to it other than to say that PA-RISC is virtually dead in the water, and so is HPUX. IBM's POWER architecture may do well with Linux on it, but AIX will eventually go away, IBM's been planning that transition for a while now.
Linux + Opteron >>>> Solaris + UltraSparc
I've been there and done it with fileservers, webservers, and oracle database servers. Sun is in denial.
Me too - they've been active in Houston as a phone-based service for at least a decade if not more. I'm not sure at what point they started doing the web-based thing, but it was at least six months ago for the Houston website. I use it all the time. Prior to that I was using a local Houston one called Takenabreak.com at least as long ago as 1.5 years back - but they recently closed down their food delivery service altogether, guess they weren't making enough profit.
I should add - yes of course they are selling x86 (And specifically Opteron) boxes with Solaris and Linux on them. But they still consider it a fringe market for edge devices and small webservers for cheapass customers. They don't "Get it", and they still think their big UltraSparc hardware is king and can stay that way for years to come.
I heard the same talk under NDA about a bit over 6 months ago. They're just hyping their warez, it's nothing special. They're talking about multi-core CPUs like what just came out from AMD, and "hyperthreading" like what Intel has had for a while. They're basically playing catchup, and poorly. If they were smart they'd have dumped future plans for the UltraSparcs a few years ago and started transitioning to Solaris on x86s and especially Opterons, and possibly built some fat custom hardware in a similar vein to the SunFire series servers around the Opteron architecture.
At most places I've been or heard about lately, if you can look professional, and act professional, nobody cares much if you have a few visible tats or odd piercings.
On the other hand, if even in the most business-like attire you can muster, you still look like a street tramp with way too many tattoos and peircings, and act like one too, you're not getting the job, even if you do have skills.
Well we use HTTP because we want to interoperate with code written by other people. Most uses of MQSeries are within an architecture controlled by one company, as an internal message-queueing method between different peices of code (threads or processes of various kinds, possibly on different machines from each other, it varies a lot). Considering how large an effort it is to engineer the type of software that MQSeries gets used in, it would be pretty trivial to throw in your own custom queueing software that's better suited to your own needs.
As someone else noted in another reply, the dust on the floor doesn't come from the floor, it just happens to land there. Put filters over the fans if you're worried, or just blow out the case with compressed air from time to time.
He claims "Looking from the front of the case, air flows in through the left side and out the right side. The front an back blow air into the case and air flows from the top of the case down and out the bottom... theoretically anyway."
Ideally, the top/bottom flow direction should be from bottom to top, since the coldest air is on the floor of your room (heat rises). Most datacenter-class stuff goes bottom to top as well, but that's just because that's where the A/C is, underneath the servers in the raised flooring.
And having two major airflows intersecting in the case (left->right vs top->bottom) seems inefficient as well.
Personally, I would have set it up with the bottom, front, and back as intakes, and the top and both sides as outflows. Only issue there is the usual power-supply placement puts it outflowing on the back, but I guess in such a custom case you could move the power supply so that the "rear" of it is blowing out one of the sides or the top.
I've never understood the corprorate programmers' obsession with purchasing message queue systems like MQSeries. You can design and code something that does the 90% that you actually need of what MQSeries does yourself in a week tops. MQSeries is so universal and overly complex for what most people want out of it, which is just reliable transactional networked message queueing with the options of in-order delivery, multiple queuers and dequeuers, and disk persistence.
Poor people are dangerous? Give me a break. When they try to commit a violent crime, the armed citizenry puts them down.
Oh what's that? You don't believe in an armed citizenry? You think we should rely on a small police force to "protect" us from the throngs of criminals? Where the fuck is America going these days?
Get a crappy job (something hands-on with physical labor involved would be best - geeks don't get enough exercise, and it will do wonders for your sleep schedule and overall mental health). Whatever this big project is that you're envisioning founding a small company around with your two friends - do that on your own time while working at your crappy job.
Even if you don't succeed, you'll learn a lot. Assuming it's a pure software project and you've got some way of sleeping and eating (see crappy job above), you don't need an internship or any financial backing to get things going.
Since you're probably already good to go on your raw talents and skills, try to focus on the more businessy and/or professional areas of the project than you would naturally. By that what I mean is rather than just hack at it all day working in your head as it comes naturally to you, you should actually try do things like:
Write up some documents as you go - roadmaps, lists of goals, intended design directions (though they always change in mid-course).
Use a proper source code repository for your work (svn, cvs, whatever), even if you're the only guy coding at the time. Comment your changes, use branches, etc. Become familiar with this aspect of software development.
Try to write your code in a very modular and generic fashion for future extensibility/hackability, rather than coding for the moment.
Work to understand who would really be using your software, interview people who you think might be representative of this target market, and get their opinions on desired features and failings of other similar products. Work this data into a sort of "user requirements" document and refer to it during development.
I've never even heard of the two-burst option, although I don't doubt it may exist in the catalog.
But honestly, I don't see why anyone chooses the burst options anyways. The MP5 (at least the original 9mm chambering - I haven't tried the.40/.45 versions which also exist) is an incredibly easy gun to control. Anyone with a modicum of experience and training can pop off a single, double, or triple at will with their trigger finger while in full-auto. The MP5 was the first full-auto weapon I ever fired in my life, and it took about 3 magazines over the coures of about 10 minutes to master controlling it.
Why can't I opt out? I'd really like to file a form with my federal and state governments, a binding agreement that says, "I will never use any social security, medicare, welfare, or unemployment benefits, ever. If I'm ever in dire need, just let me die on the sidewalk please", and then never pay the associated taxes again either.
Why am I forced into this system? I don't believe in it, I don't plan on ever using it, and if my life ever sucks so bad that I *could* use it, I wouldn't even want to. I'd rather starve to death.
If it has to be a cron job type thing that updates the internal and external websites to the "sticky" tags, then yeah I would recommend the cronjob pull the version from something else. One idea would be something like this:
SQL will enjoy a long life. There will probably be another update to the SQL standard, SQL07 or something, just about when everyone gets caught up tot he SQL99 standard of today. It does what it does very well. While the syntax is cumbersome, there aren't many better ways to represent the relational complexity. Sure, they could stand to fix the god-awful decisions that were made with regards to quoting and nesting characters and things of that nature, but the essential syntax really needs to be about like it is.
THe big thing where I see a real major follow-on to SQL emerging is in the Temporal area. There's some existing work out there, lots of papers and designs and whatnot, for Temporal SQL. SQL just isn't that great at handling time-related data, even though a lot of people coerce it into doing so. The Temporal SQL replacements/extensions attempt to remedy these, and someday whatever comes of the Temporal research will become mainstream.
In the subversion philosophy of doing things, ideally a tag shouldn't ever get changed. A tag should be pretty much a snapshot in time that stays as it is forever.
For instance, here's an example of branching/tagging the way subversion thinks of it (although you are free to twist it to other methods):
I have my main trunk, which lines in "trunk/..." in my repository. The trunk is at version 31666 right now. I decide that rev 31453 (the last good stable build from 2 days ago before I started mucking with a new feature) will be the branching point for my 1.0 stable branch. So I issue an "svn copy" command to copy rev 31453 of the turnk directory to a new place in the repository called "branches/1.x-stable". I tell the team that that branch is in feature freeze - debug it. They find a few bugs, which they commit to either the branches/1.x-stable tree, or the main trunk, and in either case they also copy their change to the other if it's applicable.
After a few weeks of debugging like this, I decide that at repository revision 31942, the "branches/1.x-stable" branch is stable enough to release the real 1.0. So I issue an "svn copy" command to copy rev 31942 of "branches/1.x-stable" to "tags/1.0". I never update this tree in tags/1.0 again. It essentially serves as a permanent record of what we released as 1.0, and a convenient spot to pull the 1.0 release from for packaging (or for comparison down the road).
After giving 1.0 to users, based on user feedback 3 new bugs were found in the 1.0 release. The coders fix these in the "branches/1.x-stable" tree, and reflect those changes back to the trunk if they're applicable (trunk may no longer have the affected code for all we know at this point). We decide that the 3 bugs were serious enough to warrant a 1.1 release to customers, so we make yet another "svn copy" off of "branches/1.x-stable", after the 3 fixes are in, as "tags/1.1", and release that copy as 1.1.
etc...etc...
To apply things to your situation (where you seem to essentially be using tagging but no branching, which is something you may wish to rethink down the line), essentially what you would do is every time you want to publish a "stable" copy internally or externally, you would just make a brand new tag. Instead of "updating" a tag named "internal" or "external" with your new code, you would create a new tag named "internal-1.1.2" or whatever you choose to version it as - but never change old tags, just make new ones.
Once you've done "svn copy" to make your new internal or external release tag, then you go to the actual webserver where you want to check it out, and in place of your previous "cvs update" on a checkout of a sticky "external" tag, you instead do an "svn switch" command from "tags/external-1.1.1" to "tags/external-1.1.2", which will alter the working copy as minimally as neccesary to switch you over to the new tag.
Information overload is part of the problem. The other part is the abusive lifestyles we lead - in part by choice and in part because the industry expects it of us. The more strenuous brain-work you're having to do on a daily basis, the more sleep you need to avoid clinical depression - yet we're expected to, want to, and are driven to sleep relatively little.
The answer is to do you magic during an 8 hour work day, and spend the rest of the day being relaxes, and get a good 8-10 hours of sleep every night - good sound sleep. If you're already suffering clinical depression of some stage, you need even more sleep to recover from it. A good diet and a healthy level of exercise also wouldn't hurt. Be sure to read the linked kuro5hin articles though on the caveats of exercise for the clinically depressed.
1) Don't hire whacked out people with a bad mental health or violence record for a sensitive position. These things are easy to check up on your know.
-and-
2) Don't be such a shitty company that your employees hate you.
You'll notice this is almost the same basic advice you'd give to someone on the dating scene to avoid messy breakups - don't date psychos, and don't treat the other person badly or there will be hell to pay later.
As you're probably aware, the old fogey founders, Hewlett and Packard, were some of the good guys. They were smart engineers and hackers, and they tried to do things right. If they were still both alive and running the show at HP, they'd be all over Linux. While HP the company has obviously spent some years over on the dark side, I'm sure a lot of old Hewlett and Packard's engineering culture still lurks in the halls of that company, and helps push them towards the right stuff.
With your specs, chances are you will either need a very beefy machine, or a distributed approach spreading the load across many machines, regardless of the software approach. But I wouldn't be surprised if a good RDBMS would outperform a flatfile approach. It is what they're designed for after all.
Slashdot Mirror
The really ideal solution would be a p2p backup network. Each client has their own encryption keys, and agrees that for every X kbytes of local data they need backed up, they're willing to store 3X worth of data from others. Your data is encrypted with your key before being sent out to the p2p network, which is designed to keep a minimum of 3 remote copies of your data out there - if less than 3 copies are detected for any decent amount of time, it just makes more copies on other machines. When you need your data, all you need is your key (it's on a USB drive and/or floppy, or whatever) to decrypt the copies you pull from the p2p backup service.
Bullshit.
Sun has not been selling multicore UltraSparcs at all, unless they started within the past 4 months or so. They may have been claiming they exist, but they aren't for sale (I haven't looked in 4 months or so, could be now - but not 1-2 years like you claim).
I wasn't attacking POWER or PA-RISC, only Sun, so there was no need for the rest of your crap, and I won't respond to it other than to say that PA-RISC is virtually dead in the water, and so is HPUX. IBM's POWER architecture may do well with Linux on it, but AIX will eventually go away, IBM's been planning that transition for a while now.
Linux + Opteron >>>> Solaris + UltraSparc
I've been there and done it with fileservers, webservers, and oracle database servers. Sun is in denial.
Me too - they've been active in Houston as a phone-based service for at least a decade if not more. I'm not sure at what point they started doing the web-based thing, but it was at least six months ago for the Houston website. I use it all the time. Prior to that I was using a local Houston one called Takenabreak.com at least as long ago as 1.5 years back - but they recently closed down their food delivery service altogether, guess they weren't making enough profit.
Flamebait? Give me a break...
I should add - yes of course they are selling x86 (And specifically Opteron) boxes with Solaris and Linux on them. But they still consider it a fringe market for edge devices and small webservers for cheapass customers. They don't "Get it", and they still think their big UltraSparc hardware is king and can stay that way for years to come.
I heard the same talk under NDA about a bit over 6 months ago. They're just hyping their warez, it's nothing special. They're talking about multi-core CPUs like what just came out from AMD, and "hyperthreading" like what Intel has had for a while. They're basically playing catchup, and poorly. If they were smart they'd have dumped future plans for the UltraSparcs a few years ago and started transitioning to Solaris on x86s and especially Opterons, and possibly built some fat custom hardware in a similar vein to the SunFire series servers around the Opteron architecture.
At most places I've been or heard about lately, if you can look professional, and act professional, nobody cares much if you have a few visible tats or odd piercings.
On the other hand, if even in the most business-like attire you can muster, you still look like a street tramp with way too many tattoos and peircings, and act like one too, you're not getting the job, even if you do have skills.
Well we use HTTP because we want to interoperate with code written by other people. Most uses of MQSeries are within an architecture controlled by one company, as an internal message-queueing method between different peices of code (threads or processes of various kinds, possibly on different machines from each other, it varies a lot). Considering how large an effort it is to engineer the type of software that MQSeries gets used in, it would be pretty trivial to throw in your own custom queueing software that's better suited to your own needs.
As someone else noted in another reply, the dust on the floor doesn't come from the floor, it just happens to land there. Put filters over the fans if you're worried, or just blow out the case with compressed air from time to time.
He claims "Looking from the front of the case, air flows in through the left side and out the right side. The front an back blow air into the case and air flows from the top of the case down and out the bottom... theoretically anyway."
Ideally, the top/bottom flow direction should be from bottom to top, since the coldest air is on the floor of your room (heat rises). Most datacenter-class stuff goes bottom to top as well, but that's just because that's where the A/C is, underneath the servers in the raised flooring.
And having two major airflows intersecting in the case (left->right vs top->bottom) seems inefficient as well.
Personally, I would have set it up with the bottom, front, and back as intakes, and the top and both sides as outflows. Only issue there is the usual power-supply placement puts it outflowing on the back, but I guess in such a custom case you could move the power supply so that the "rear" of it is blowing out one of the sides or the top.
I've never understood the corprorate programmers' obsession with purchasing message queue systems like MQSeries. You can design and code something that does the 90% that you actually need of what MQSeries does yourself in a week tops. MQSeries is so universal and overly complex for what most people want out of it, which is just reliable transactional networked message queueing with the options of in-order delivery, multiple queuers and dequeuers, and disk persistence.
Perhaps this will push game engine creators more in the direction of open standards like OpenGL that can exist on both operating systems.
Those stats sound roughly comparable, if anything slightly lower, than what a private company I know of runs for seismic data processing.
Poor people are dangerous? Give me a break. When they try to commit a violent crime, the armed citizenry puts them down.
Oh what's that? You don't believe in an armed citizenry? You think we should rely on a small police force to "protect" us from the throngs of criminals? Where the fuck is America going these days?
Get a crappy job (something hands-on with physical labor involved would be best - geeks don't get enough exercise, and it will do wonders for your sleep schedule and overall mental health). Whatever this big project is that you're envisioning founding a small company around with your two friends - do that on your own time while working at your crappy job.
Even if you don't succeed, you'll learn a lot. Assuming it's a pure software project and you've got some way of sleeping and eating (see crappy job above), you don't need an internship or any financial backing to get things going.
Since you're probably already good to go on your raw talents and skills, try to focus on the more businessy and/or professional areas of the project than you would naturally. By that what I mean is rather than just hack at it all day working in your head as it comes naturally to you, you should actually try do things like:
The only fire-control configurations that I've actually seen in real-world existance on original factory NFA-regulated HK MP5's in the US are:
safe/semi/3-burst
safe/semi/auto
safe/semi/3-
I've never even heard of the two-burst option, although I don't doubt it may exist in the catalog.
But honestly, I don't see why anyone chooses the burst options anyways. The MP5 (at least the original 9mm chambering - I haven't tried the
I would recommend a Barrett
Why can't I opt out? I'd really like to file a form with my federal and state governments, a binding agreement that says, "I will never use any social security, medicare, welfare, or unemployment benefits, ever. If I'm ever in dire need, just let me die on the sidewalk please", and then never pay the associated taxes again either.
Why am I forced into this system? I don't believe in it, I don't plan on ever using it, and if my life ever sucks so bad that I *could* use it, I wouldn't even want to. I'd rather starve to death.
If it has to be a cron job type thing that updates the internal and external websites to the "sticky" tags, then yeah I would recommend the cronjob pull the version from something else. One idea would be something like this:
. .]a l-release
/tmp/relnum /tmp/relnum` /web/root
myproj/trunk/[...]
myproj/tags/external-1.1/[.
myproj/tags/external-1.2/[...]
myproj/extern
Where the tags work as I outlined, and "myproj/external-release" is a text file which is manually updated to read "1.1" or "1.2" or whatever.
Then the cronjob on the production server essentially does
svn checkout svn://mysvnsvr/myproj/external-release
svn switch svn://mysvnsvr/myproj/tags/external-`cat
Or what-have-you for the specifics.
SQL will enjoy a long life. There will probably be another update to the SQL standard, SQL07 or something, just about when everyone gets caught up tot he SQL99 standard of today. It does what it does very well. While the syntax is cumbersome, there aren't many better ways to represent the relational complexity. Sure, they could stand to fix the god-awful decisions that were made with regards to quoting and nesting characters and things of that nature, but the essential syntax really needs to be about like it is.
THe big thing where I see a real major follow-on to SQL emerging is in the Temporal area. There's some existing work out there, lots of papers and designs and whatnot, for Temporal SQL. SQL just isn't that great at handling time-related data, even though a lot of people coerce it into doing so. The Temporal SQL replacements/extensions attempt to remedy these, and someday whatever comes of the Temporal research will become mainstream.
In the subversion philosophy of doing things, ideally a tag shouldn't ever get changed. A tag should be pretty much a snapshot in time that stays as it is forever.
For instance, here's an example of branching/tagging the way subversion thinks of it (although you are free to twist it to other methods):
I have my main trunk, which lines in "trunk/..." in my repository. The trunk is at version 31666 right now. I decide that rev 31453 (the last good stable build from 2 days ago before I started mucking with a new feature) will be the branching point for my 1.0 stable branch. So I issue an "svn copy" command to copy rev 31453 of the turnk directory to a new place in the repository called "branches/1.x-stable". I tell the team that that branch is in feature freeze - debug it. They find a few bugs, which they commit to either the branches/1.x-stable tree, or the main trunk, and in either case they also copy their change to the other if it's applicable.
After a few weeks of debugging like this, I decide that at repository revision 31942, the "branches/1.x-stable" branch is stable enough to release the real 1.0. So I issue an "svn copy" command to copy rev 31942 of "branches/1.x-stable" to "tags/1.0". I never update this tree in tags/1.0 again. It essentially serves as a permanent record of what we released as 1.0, and a convenient spot to pull the 1.0 release from for packaging (or for comparison down the road).
After giving 1.0 to users, based on user feedback 3 new bugs were found in the 1.0 release. The coders fix these in the "branches/1.x-stable" tree, and reflect those changes back to the trunk if they're applicable (trunk may no longer have the affected code for all we know at this point). We decide that the 3 bugs were serious enough to warrant a 1.1 release to customers, so we make yet another "svn copy" off of "branches/1.x-stable", after the 3 fixes are in, as "tags/1.1", and release that copy as 1.1.
etc...etc...
To apply things to your situation (where you seem to essentially be using tagging but no branching, which is something you may wish to rethink down the line), essentially what you would do is every time you want to publish a "stable" copy internally or externally, you would just make a brand new tag. Instead of "updating" a tag named "internal" or "external" with your new code, you would create a new tag named "internal-1.1.2" or whatever you choose to version it as - but never change old tags, just make new ones.
Once you've done "svn copy" to make your new internal or external release tag, then you go to the actual webserver where you want to check it out, and in place of your previous "cvs update" on a checkout of a sticky "external" tag, you instead do an "svn switch" command from "tags/external-1.1.1" to "tags/external-1.1.2", which will alter the working copy as minimally as neccesary to switch you over to the new tag.
Information overload is part of the problem. The other part is the abusive lifestyles we lead - in part by choice and in part because the industry expects it of us. The more strenuous brain-work you're having to do on a daily basis, the more sleep you need to avoid clinical depression - yet we're expected to, want to, and are driven to sleep relatively little.
The answer is to do you magic during an 8 hour work day, and spend the rest of the day being relaxes, and get a good 8-10 hours of sleep every night - good sound sleep. If you're already suffering clinical depression of some stage, you need even more sleep to recover from it. A good diet and a healthy level of exercise also wouldn't hurt. Be sure to read the linked kuro5hin articles though on the caveats of exercise for the clinically depressed.
1) Don't hire whacked out people with a bad mental health or violence record for a sensitive position. These things are easy to check up on your know.
-and-
2) Don't be such a shitty company that your employees hate you.
You'll notice this is almost the same basic advice you'd give to someone on the dating scene to avoid messy breakups - don't date psychos, and don't treat the other person badly or there will be hell to pay later.
As you're probably aware, the old fogey founders, Hewlett and Packard, were some of the good guys. They were smart engineers and hackers, and they tried to do things right. If they were still both alive and running the show at HP, they'd be all over Linux. While HP the company has obviously spent some years over on the dark side, I'm sure a lot of old Hewlett and Packard's engineering culture still lurks in the halls of that company, and helps push them towards the right stuff.
With your specs, chances are you will either need a very beefy machine, or a distributed approach spreading the load across many machines, regardless of the software approach. But I wouldn't be surprised if a good RDBMS would outperform a flatfile approach. It is what they're designed for after all.