Re:and how is there any net difference?
on
Just Add, Umm, Water
·
· Score: 4, Insightful
Would you mind explaining to me, Private Genius, how there's a net difference in water intake between those two scenarios?
Not at all.:)
This allows you to reclaim water that otherwise you would have disposed of. So, if you have 2 canteens' worth of potable water and a puddle, you can drink those canteens, and then reclaim however much you need to rehydrate your meal from the puddle. This gets you 2 canteens plus part of a puddle's worth of hydration. If you don't have this, you only get 2 canteens' worth.
Alternatively you can reuse those two canteens' worth by using your urine to rehydrate your food, getting double-use out of at least some of that water.
Yes, and by using the clean water you have for drinking instead of for rehydrating field rations, it lasts that much longer, and therefore, you do too.
I still swear by hardware RAID from the big guys (and probably would have used the second offsite server remotely rather than attempt to move it after the first one failed), but I can see where you're coming from. Working with no budget sucks. Best of luck finding a new position..:)
> Stability is a top-level priority when you're a sysadmin.
(insert picture of me with a confused look)
I've managed a couple of Linux servers at work for just over two years. Stability is important, but when your systems are connected to the Internet, you *have* to continually update software. Period. You can say all you want that stability is important, but when you login to your system and it's spewing-out spam and/var/log is gone, keeping things up to date suddenly becomes more important. It's a no-win situation, but I think your statement is just plain wrong when talking about systems connected to public networks.
Tell me, what good are your up-to-date servers if they can't provide the services you depend on them for? Ensuring predictable behaviour is of paramount importance. Yes, of course you will have to patch your systems, more often if they're internet-facing. This guy is talking about backup servers though, which should've been hidden on the other end of a VPN somewhere and inaccessible to the internet at large. Backups must be stable, or they're useless. I'm not discounting security here; what I'm saying is that you can't panic and install every new update on every server without testing them.
If your systems were rooted, yes, that sucks and you must fix it in the immediate term. On an ongoing basis though, instead of going nuts with patches, you'd be better served (in my opinion) by working more on defence-in-depth. Jail your processes, use different user accounts, only allow servers that need to talk to each other to do so, crank down your firewall rulesets, keep internet-facing servers DMZ-ed, etc. Defence-in-depth and using workarounds as published in the advisories is what buys you the time to test the patches. Many times following good security practices will make bugs that crop up ineffectual on your systems. Sure, you still update them and you must pay attention to n-level combinations of exploits, but it's not the same kind of panic-patching that would inhibit your ability to keep things stable.
He said it was oopsing when copying files. How is that not Linux's fault? I agree that he should have NEVER run 2.6 or LVM2, but not blaming Linux is going too far.
I'm not saying the code is/was flawless. Linux has bugs just like everything else, and a kernel oops while copying files is clearly a bug. My point was that rolling out unstable software is a bad idea, and that as a sysadmin, it was his responsibility to not do that.:) Do you blindly trust your vendors when they give you software to install, or do you test them to make sure they suit your business and technical needs? Everybody and their brother will throw software at you that claims to do X, Y, and Z, but at the end of the day it's your ass on the line to make sure it actually works.
Yes, Linux is responsible for the kernel oops. The failure of the business as the poster reported though, lays squarely on the shoulders of the sysadmin(s) and management for not designing and testing appropriately. Obviously if they won't give you the money to do it right after you've made a solid case for why it's important, you have to do the best you can. Rolling out unstable software on servers that should be sheltered and must be stable enough to use as your last lifeline in case of disaster is a really bad call on the part of the sysadmin(s), and there are few circumstances I can think of under which you don't have any other choice but to do so.
Of course we tested it. We looked at it every single damn day. We even ran some of the larger read-only reports against the off-site systems. It just wouldn't come-up and run after a power cycle. They ran fine for six months with a few power cycles.
Looking at it is not testing it. Running some of the reports is not testing it. Testing it means recreating a disaster environment in detail, and then seeing what works and what doesn't. Why are you power-cycling your offsite backup servers after a failure? Why aren't you simply pulling the data off of them and rebuilding your local machines?
Further, I'd also ask why you're using software RAID on mission-critical servers and why you don't have backups on removable media in a vault somewhere. These alone lead me to question your judgement. I read your reply to another respondant about "when you get beyond a certain size, removable media just isn't workable.". Frankly, this is bullshit. There are folks out there backing up much more data than you onto removable media and shipping it offsite nightly. There is no excuse for not doing this unless you're Google and have that level of systems redundancy and proven availability.
> You MUST test it.
Again, why would you say that? Of course we checked to make sure they were running. We've even run the production system off of one or the other backups when the power was off at our main site. We not only tested them. We used them in production. They just failed due to a software problem that didn't show-up before.
I'm saying that because it appears clear that you never thoroughly tested it. A spontaneous failure of two properly-configured remote backup servers at the same time, in different facilities, in different states, on different power and network feeds is highly unlikely.
If the software problem spontaneously showed up in both offsite backups at the same time, which just happened to be right after your local servers were destroyed, that's a helluva coincidence, don't you think?
Something here doesn't jibe. I'm having trouble believing that your offsite backup servers were so unstable that they *both* spontaneously croaked when a disaster occurred, and you never noticed any problems beforehand, in spite of rigorous testing. If they were this unstable in spite of following good practices for design and testing, please exit the IT business and find something where you're far away from sharp objects, moving vehicles, and steep dropoffs. You're far too unlucky to be managing critical servers.
Moral of the story, don't trust your data to unstable software.
I'm sorry you had to learn this lesson the hard way. Stability is a top-level priority when you're a sysadmin.
We had two off-site backup systems in different states. Both were running the same system except with software RAID5 + Reiserfs. I couldn't get either to work long enough to copy the data off.
If you never tested your off-site backup systems, you can't trust them. Period. You had *two* off-site backups that failed. Whose responsibility is it to make sure your backups are tested and functioning?
We spent a lot of money on servers, bandwidth, and safe off-site co-lo, but that still wasn't good enough.
If you never tested your backup/restore system, your colo may have been "safe", but your data never was. I'm sorry, but you made some rookie sysadmin mistakes and your entire company got burned by them. It's not Linux's fault you never tested your backup/restore strategy. You simply cannot just throw something together and expect it to work perfectly on the first run-through. You MUST test it.
Folks with million-dollar support contracts test their backup/restore strategies, and they're running on some of the most expensive and time-tested software in the business, not to mention they can get direct access to the developers through their support contracts. You threw something together on your own, ran different configurations on your primary and backup servers, and didn't test it to make sure it all worked.
Wow. I suffered through high school and college calculus (engineering, no less) not knowing about that either (by the time I got to diff eqs it was too late and I wasn't able to connect it back to the beginning). Both notations were used, and mixed together, but the braindead-obvious statement you made above has restored some hope that maybe I don't despise calculus, just the folks who tried to "teach" it to me.
Thank you. Seriously, I mean that.
Hmm..I don't suppose you'd be willing to outline the purpose of the dx in an indefinite integral, would you?:)
While your warning is certainly appreciated, wouldn't it be more helpful to just encourage folks to line their backpack with plastic?:)
You can get rolls of plastic for cheap these days, and it wouldn't be all that hard to even double- or triple-line your battery compartment with it. It's my understanding that the garden variety clear plastic you can get at any home improvement store is impervious to sulfuric acid (and many others). I'm one of those folks who believes home experimenting and proper safety procedures don't *have* to be mutually exclusive..;)
You've gotta be kidding me. SPF requires SRS for folks who use forwarding services. This is all over the website. It's also pretty clear from what I've seen that *all* the good solutions to the forged email problem will break forwarding as we do it today. That's just the way it goes. We can't afford to be as trusting today as we could when email was invented. It sucks, but it's reality.
Yes, folks need to implement things properly. That's largely why SPF has different fail modes, so you can slowly phase it in. As it gains more momentum, the folks who run mail servers will have to play along in order to have their systems reap the rewards of non-spoofed email. Welcome to the wonderful wide world of cooperation. There's this thing called the internet that works largely because of this. Perhaps you've heard of it?
Another fact about this story that leaves me wondering -- the Klown website very sneakily says (paraphrased) as of 24 April is licensed under... Well, inquiring minds want to know: PREVIOUS to 24 April, under which (if any) license was it released under?
It's not sneaky. He released his stuff under the CC effective April 24. Previous to that he granted permission on a case-by-case basis to folks who asked if they could use his work, and standard copyright protections applied.
(FYI--I know him; I'm not just pulling this out of my ass..)
So what is it good for? Perhaps marketing? "Microsoft DOES contribute to open source! We are good!" -- perhaps a cover-your-ass attempt if some OSS does make it big, Microsoft might say "Windows makes OSS easier to install!"?
It's fantastic for marketing. It's also fantastic for business. Anything that helps other people write apps that install better on Windows helps Microsoft.
This isn't so hard to understand...they get OSS PR benefits, as well as apps that make their OS look better. What's not to like from their end of it?
Decentralization is becoming a broad-ranging trend in our society.
Anybody else wondering if this will be like the PC 'revolution' in the late eighties/early nineties?
Effectively, everybody and their brother went out and bought one so they could feel 'empowered' and 'independent', and only after a decade or so did folks figure out that maybe it wasn't such a bright idea after all--maybe there really was something to that old client/server model. There are efficiencies of scale in the real world, and plenty of reasons to keep certain things centralised. Personally, I like having everything under my personal control and am perfectly capable of managing it efficiently. There are plenty of folks who aren't, though, and who will leap on the decentralisation bandwagon without thinking it through first. A trend to decentralise doesn't have to be problematic per se, but I think we'd be best to think long and hard about it before proclaiming it as the Next Big Thing.
I used to be a big "geek". Was always interested in the latest processor, RAM technology, etc. Now, I couldnt give a shit.
I don't give a damn about that stuff anymore either. The biggest change, however, is that I'm now a much better designer than I ever was. Knowledge of the latest PC9900 RAM doesn't make my systems any more stable, nor does it help me design things that fit business needs. I know plenty of folks obsessed with that level of technical arcanae who can't design their way out of a wet paper bag.
Thinking that intimate knowledge of that kind of crap is useful to software folks is like thinking knowledge of various composites used in baseball bats is going to help you make the Major Leagues. Sure, it might help to be familiar with it, but you're gonna end up using a wooden bat anyhow. You might want to spend more time focusing on other things--like your swing and fielding abilities.
I've discovered that knowledge of arcanae does not a good designer make. Solid knowledge of architectural and engineering processes, on the other hand, are worth their weight in gold. It all depends on what you consider to be important.
Actually, most of the people I consider peers seem to enjoy what they do. Sure, we can sit around and share amusing stories of stupid stuff that pisses us off, but we by and large *like* our jobs.
I'm not sure I'd want to hang around a bunch of people who bitched constantly. BOFH jokes are one thing, but if your work life is really like that--and you can't handle it, you need to find another field.
You're not the only one. Has anybody else noticed that the trend lately has been for making everything smaller and faster, and everybody seems to be ignoring the quality?
This has happened with lossy compression for music; it's happened with cellular technology that only has to be good enough for you to barely make out what the caller is saying; it's happened with parts that are now designed to break way sooner than they ever used to (printers are a fabulous example).
Is there somebody out there who's still making things with serious quality? I want a cellphone that sounds as pristine as a voice call over ISDN. I want lossless compression for my music (yes, I use FLAC) that I'd like to purchase online. I want a printer that lasts like an HP LaserJet 4 that was made this year.
Somebody please tell me I'm just looking in the wrong places...
In no way do I want for there to be a draft. The part I disagree with is that the military is an economic entity like any other. I'm most certainly not in favour of the draft, nor do I think that we're in such desperate times that one should be required. I think the over-extension of our military forces is a bad thing--and that the solution is to bring them home. Please don't misunderstand my perspective; I agree that a draft is a bad idea, I just happen to feel that justifying that perspective using economic principles of supply and demand is a specious argument, no matter how convenient it is.
Sorry to pick on you for this, but I'm seeing this argument all over the place today.
Who said the military was an economic organisation? They may have to deal with some of the same issues as private companies during peacetime, but I think it's important to remember that the purpose of the military is to ensure the continued existence of our political and economic system, not to be a profit-generating part of it.
It may be nice to have an economic system that could be protected by an organisation which plays by its rules, but the realities of the world we live in do not always allow such romantic visions to be effective.
I wish Congress could tell me just what is the American Way to fill a need.. negotiate for it, or just use a gun.
I'd posit that the American Way is to get what you want. At some point there was a rumour about adding 'by hard work' in there, or maybe something about Freedom, but I'm not sure the base definition I've offered is all that far off from the reality of the situation.
I have no desire to leave my great job, or my wonderful house either. At a certain point I put aside some of my ideas about how a country should be run though, and accept that the best thing I can do is grab a rifle and stand to. Things don't have to be done the way I'd prefer in order for me to contribute, and I feel that if the elected government considers this country sufficiently-threatened, it's time to go.
That doesn't mean I'll like it any better, but I'm just as much a part of the system as anybody else is, and I accept that part of being a citizen in a 'democratic' country is holding up my end of the deal. Part of that means I don't always get my way.
This type of action itself does not reflect poorly upon our community (kudos for clean phrasing, btw), but once the trolls get ahold of it and DoS the guy, we will come off poorly in the media.
Stay the course. Let the law do it's thing. Mod parent down quickly to minimize the community's exposure.
Your phone may have the same problem mine did. I have the S46 as well, and found that it will grab the strongest signal available, sometimes grabbing TDMA/D-AMPS in areas where it should have been getting GSM coverage from AT&T towers. This resulted in some weird 'not able to call' errors, and the tech support folks suggested switching the phone to GSM only when in highly-covered areas (this problem was occurring in Hartford, CT). That resolved the issues. Now I generally leave it on GSM-only all the time unless I'm headed out into the boonies.
This is also good to do because calls will only transfer in one direction. So, if you initiate a call while using GSM and move into an area where you lose GSM coverage, but maintain TDMA/D-AMPS coverage, your call will move seamlessly. Once you're using TDMA/D-AMPS, however, when the phone tries to jump back over to GSM your call will drop. That really pissed me off a couple times until tech support told me why and how to fix it.:)
I'm not running an open relay. Mail is coming in, sent to my users, with a forged From: address that uses those non-existent addresses @[ourdomain].com. I'm currently working on management about getting a *nix machine in place as a mail gateway so I can do proper filtering to get rid of some of this crap. SPF seems to be the most elegant solution to this particular problem, certainly for our purposes.
Slashdot Mirror
Would you mind explaining to me, Private Genius, how there's a net difference in water intake between those two scenarios?
:)
Not at all.
This allows you to reclaim water that otherwise you would have disposed of. So, if you have 2 canteens' worth of potable water and a puddle, you can drink those canteens, and then reclaim however much you need to rehydrate your meal from the puddle. This gets you 2 canteens plus part of a puddle's worth of hydration. If you don't have this, you only get 2 canteens' worth.
Alternatively you can reuse those two canteens' worth by using your urine to rehydrate your food, getting double-use out of at least some of that water.
Yes, and by using the clean water you have for drinking instead of for rehydrating field rations, it lasts that much longer, and therefore, you do too.
Ouch.
:)
I still swear by hardware RAID from the big guys (and probably would have used the second offsite server remotely rather than attempt to move it after the first one failed), but I can see where you're coming from. Working with no budget sucks. Best of luck finding a new position..
> Stability is a top-level priority when you're a sysadmin.
/var/log is gone, keeping things up to date suddenly becomes more important. It's a no-win situation, but I think your statement is just plain wrong when talking about systems connected to public networks.
:) Do you blindly trust your vendors when they give you software to install, or do you test them to make sure they suit your business and technical needs? Everybody and their brother will throw software at you that claims to do X, Y, and Z, but at the end of the day it's your ass on the line to make sure it actually works.
(insert picture of me with a confused look)
I've managed a couple of Linux servers at work for just over two years. Stability is important, but when your systems are connected to the Internet, you *have* to continually update software. Period. You can say all you want that stability is important, but when you login to your system and it's spewing-out spam and
Tell me, what good are your up-to-date servers if they can't provide the services you depend on them for? Ensuring predictable behaviour is of paramount importance. Yes, of course you will have to patch your systems, more often if they're internet-facing. This guy is talking about backup servers though, which should've been hidden on the other end of a VPN somewhere and inaccessible to the internet at large. Backups must be stable, or they're useless. I'm not discounting security here; what I'm saying is that you can't panic and install every new update on every server without testing them.
If your systems were rooted, yes, that sucks and you must fix it in the immediate term. On an ongoing basis though, instead of going nuts with patches, you'd be better served (in my opinion) by working more on defence-in-depth. Jail your processes, use different user accounts, only allow servers that need to talk to each other to do so, crank down your firewall rulesets, keep internet-facing servers DMZ-ed, etc. Defence-in-depth and using workarounds as published in the advisories is what buys you the time to test the patches. Many times following good security practices will make bugs that crop up ineffectual on your systems. Sure, you still update them and you must pay attention to n-level combinations of exploits, but it's not the same kind of panic-patching that would inhibit your ability to keep things stable.
He said it was oopsing when copying files. How is that not Linux's fault? I agree that he should have NEVER run 2.6 or LVM2, but not blaming Linux is going too far.
I'm not saying the code is/was flawless. Linux has bugs just like everything else, and a kernel oops while copying files is clearly a bug. My point was that rolling out unstable software is a bad idea, and that as a sysadmin, it was his responsibility to not do that.
Yes, Linux is responsible for the kernel oops. The failure of the business as the poster reported though, lays squarely on the shoulders of the sysadmin(s) and management for not designing and testing appropriately. Obviously if they won't give you the money to do it right after you've made a solid case for why it's important, you have to do the best you can. Rolling out unstable software on servers that should be sheltered and must be stable enough to use as your last lifeline in case of disaster is a really bad call on the part of the sysadmin(s), and there are few circumstances I can think of under which you don't have any other choice but to do so.
> If you never tested your backup/restore system
Of course we tested it. We looked at it every single damn day. We even ran some of the larger read-only reports against the off-site systems. It just wouldn't come-up and run after a power cycle. They ran fine for six months with a few power cycles.
Looking at it is not testing it. Running some of the reports is not testing it. Testing it means recreating a disaster environment in detail, and then seeing what works and what doesn't. Why are you power-cycling your offsite backup servers after a failure? Why aren't you simply pulling the data off of them and rebuilding your local machines?
Further, I'd also ask why you're using software RAID on mission-critical servers and why you don't have backups on removable media in a vault somewhere. These alone lead me to question your judgement. I read your reply to another respondant about "when you get beyond a certain size, removable media just isn't workable.". Frankly, this is bullshit. There are folks out there backing up much more data than you onto removable media and shipping it offsite nightly. There is no excuse for not doing this unless you're Google and have that level of systems redundancy and proven availability.
> You MUST test it.
Again, why would you say that? Of course we checked to make sure they were running. We've even run the production system off of one or the other backups when the power was off at our main site. We not only tested them. We used them in production. They just failed due to a software problem that didn't show-up before.
I'm saying that because it appears clear that you never thoroughly tested it. A spontaneous failure of two properly-configured remote backup servers at the same time, in different facilities, in different states, on different power and network feeds is highly unlikely.
If the software problem spontaneously showed up in both offsite backups at the same time, which just happened to be right after your local servers were destroyed, that's a helluva coincidence, don't you think?
Something here doesn't jibe. I'm having trouble believing that your offsite backup servers were so unstable that they *both* spontaneously croaked when a disaster occurred, and you never noticed any problems beforehand, in spite of rigorous testing. If they were this unstable in spite of following good practices for design and testing, please exit the IT business and find something where you're far away from sharp objects, moving vehicles, and steep dropoffs. You're far too unlucky to be managing critical servers.
Moral of the story, don't trust your data to unstable software.
I'm sorry you had to learn this lesson the hard way. Stability is a top-level priority when you're a sysadmin.
We had two off-site backup systems in different states. Both were running the same system except with software RAID5 + Reiserfs. I couldn't get either to work long enough to copy the data off.
If you never tested your off-site backup systems, you can't trust them. Period. You had *two* off-site backups that failed. Whose responsibility is it to make sure your backups are tested and functioning?
We spent a lot of money on servers, bandwidth, and safe off-site co-lo, but that still wasn't good enough.
If you never tested your backup/restore system, your colo may have been "safe", but your data never was. I'm sorry, but you made some rookie sysadmin mistakes and your entire company got burned by them. It's not Linux's fault you never tested your backup/restore strategy. You simply cannot just throw something together and expect it to work perfectly on the first run-through. You MUST test it.
Folks with million-dollar support contracts test their backup/restore strategies, and they're running on some of the most expensive and time-tested software in the business, not to mention they can get direct access to the developers through their support contracts. You threw something together on your own, ran different configurations on your primary and backup servers, and didn't test it to make sure it all worked.
Exactly how is this Linux's fault again?
Wow. I suffered through high school and college calculus (engineering, no less) not knowing about that either (by the time I got to diff eqs it was too late and I wasn't able to connect it back to the beginning). Both notations were used, and mixed together, but the braindead-obvious statement you made above has restored some hope that maybe I don't despise calculus, just the folks who tried to "teach" it to me.
:)
Thank you. Seriously, I mean that.
Hmm..I don't suppose you'd be willing to outline the purpose of the dx in an indefinite integral, would you?
While your warning is certainly appreciated, wouldn't it be more helpful to just encourage folks to line their backpack with plastic? :)
;)
You can get rolls of plastic for cheap these days, and it wouldn't be all that hard to even double- or triple-line your battery compartment with it. It's my understanding that the garden variety clear plastic you can get at any home improvement store is impervious to sulfuric acid (and many others). I'm one of those folks who believes home experimenting and proper safety procedures don't *have* to be mutually exclusive..
You've gotta be kidding me. SPF requires SRS for folks who use forwarding services. This is all over the website. It's also pretty clear from what I've seen that *all* the good solutions to the forged email problem will break forwarding as we do it today. That's just the way it goes. We can't afford to be as trusting today as we could when email was invented. It sucks, but it's reality.
Yes, folks need to implement things properly. That's largely why SPF has different fail modes, so you can slowly phase it in. As it gains more momentum, the folks who run mail servers will have to play along in order to have their systems reap the rewards of non-spoofed email. Welcome to the wonderful wide world of cooperation. There's this thing called the internet that works largely because of this. Perhaps you've heard of it?
Another fact about this story that leaves me wondering -- the Klown website very sneakily says (paraphrased) as of 24 April is licensed under ... Well, inquiring minds want to know: PREVIOUS to 24 April, under which (if any) license was it released under?
It's not sneaky. He released his stuff under the CC effective April 24. Previous to that he granted permission on a case-by-case basis to folks who asked if they could use his work, and standard copyright protections applied.
(FYI--I know him; I'm not just pulling this out of my ass..)
I have maple floors in mine. ;)
Um...I wish that were true, but this injunction was brought in Munich, which has very little impact on cases currently pending in the United States.
;)
SCO has behaved very differently in Germany, from what I've read--and apparently for good reason.
So what is it good for? Perhaps marketing? "Microsoft DOES contribute to open source! We are good!" -- perhaps a cover-your-ass attempt if some OSS does make it big, Microsoft might say "Windows makes OSS easier to install!"?
It's fantastic for marketing. It's also fantastic for business. Anything that helps other people write apps that install better on Windows helps Microsoft.
This isn't so hard to understand...they get OSS PR benefits, as well as apps that make their OS look better. What's not to like from their end of it?
Decentralization is becoming a broad-ranging trend in our society.
Anybody else wondering if this will be like the PC 'revolution' in the late eighties/early nineties?
Effectively, everybody and their brother went out and bought one so they could feel 'empowered' and 'independent', and only after a decade or so did folks figure out that maybe it wasn't such a bright idea after all--maybe there really was something to that old client/server model. There are efficiencies of scale in the real world, and plenty of reasons to keep certain things centralised. Personally, I like having everything under my personal control and am perfectly capable of managing it efficiently. There are plenty of folks who aren't, though, and who will leap on the decentralisation bandwagon without thinking it through first. A trend to decentralise doesn't have to be problematic per se, but I think we'd be best to think long and hard about it before proclaiming it as the Next Big Thing.
Dan
I used to be a big "geek". Was always interested in the latest processor, RAM technology, etc. Now, I couldnt give a shit.
I don't give a damn about that stuff anymore either. The biggest change, however, is that I'm now a much better designer than I ever was. Knowledge of the latest PC9900 RAM doesn't make my systems any more stable, nor does it help me design things that fit business needs. I know plenty of folks obsessed with that level of technical arcanae who can't design their way out of a wet paper bag.
Thinking that intimate knowledge of that kind of crap is useful to software folks is like thinking knowledge of various composites used in baseball bats is going to help you make the Major Leagues. Sure, it might help to be familiar with it, but you're gonna end up using a wooden bat anyhow. You might want to spend more time focusing on other things--like your swing and fielding abilities.
I've discovered that knowledge of arcanae does not a good designer make. Solid knowledge of architectural and engineering processes, on the other hand, are worth their weight in gold. It all depends on what you consider to be important.
Dan
Actually, most of the people I consider peers seem to enjoy what they do. Sure, we can sit around and share amusing stories of stupid stuff that pisses us off, but we by and large *like* our jobs.
I'm not sure I'd want to hang around a bunch of people who bitched constantly. BOFH jokes are one thing, but if your work life is really like that--and you can't handle it, you need to find another field.
You're not the only one. Has anybody else noticed that the trend lately has been for making everything smaller and faster, and everybody seems to be ignoring the quality?
This has happened with lossy compression for music; it's happened with cellular technology that only has to be good enough for you to barely make out what the caller is saying; it's happened with parts that are now designed to break way sooner than they ever used to (printers are a fabulous example).
Is there somebody out there who's still making things with serious quality? I want a cellphone that sounds as pristine as a voice call over ISDN. I want lossless compression for my music (yes, I use FLAC) that I'd like to purchase online. I want a printer that lasts like an HP LaserJet 4 that was made this year.
Somebody please tell me I'm just looking in the wrong places...
Dan
I'm not glib about it at all.
In no way do I want for there to be a draft. The part I disagree with is that the military is an economic entity like any other. I'm most certainly not in favour of the draft, nor do I think that we're in such desperate times that one should be required. I think the over-extension of our military forces is a bad thing--and that the solution is to bring them home. Please don't misunderstand my perspective; I agree that a draft is a bad idea, I just happen to feel that justifying that perspective using economic principles of supply and demand is a specious argument, no matter how convenient it is.
Dan
Sorry to pick on you for this, but I'm seeing this argument all over the place today.
Who said the military was an economic organisation? They may have to deal with some of the same issues as private companies during peacetime, but I think it's important to remember that the purpose of the military is to ensure the continued existence of our political and economic system, not to be a profit-generating part of it.
It may be nice to have an economic system that could be protected by an organisation which plays by its rules, but the realities of the world we live in do not always allow such romantic visions to be effective.
Sometimes you just need to do what works.
Dan
I wish Congress could tell me just what is the American Way to fill a need.. negotiate for it, or just use a gun.
I'd posit that the American Way is to get what you want. At some point there was a rumour about adding 'by hard work' in there, or maybe something about Freedom, but I'm not sure the base definition I've offered is all that far off from the reality of the situation.
I'm going to have to think on that a bit more.
Dan
You're not the only one.
I have no desire to leave my great job, or my wonderful house either. At a certain point I put aside some of my ideas about how a country should be run though, and accept that the best thing I can do is grab a rifle and stand to. Things don't have to be done the way I'd prefer in order for me to contribute, and I feel that if the elected government considers this country sufficiently-threatened, it's time to go.
That doesn't mean I'll like it any better, but I'm just as much a part of the system as anybody else is, and I accept that part of being a citizen in a 'democratic' country is holding up my end of the deal. Part of that means I don't always get my way.
Dan
The article said 3 full-height racks, which means 19 inches wide by 42U high, by however deep they bought, times 3. It would fit in your cubicle. :)
This type of action itself does not reflect poorly upon our community (kudos for clean phrasing, btw), but once the trolls get ahold of it and DoS the guy, we will come off poorly in the media.
Stay the course. Let the law do it's thing. Mod parent down quickly to minimize the community's exposure.
Dan
Your phone may have the same problem mine did. I have the S46 as well, and found that it will grab the strongest signal available, sometimes grabbing TDMA/D-AMPS in areas where it should have been getting GSM coverage from AT&T towers. This resulted in some weird 'not able to call' errors, and the tech support folks suggested switching the phone to GSM only when in highly-covered areas (this problem was occurring in Hartford, CT). That resolved the issues. Now I generally leave it on GSM-only all the time unless I'm headed out into the boonies.
:)
This is also good to do because calls will only transfer in one direction. So, if you initiate a call while using GSM and move into an area where you lose GSM coverage, but maintain TDMA/D-AMPS coverage, your call will move seamlessly. Once you're using TDMA/D-AMPS, however, when the phone tries to jump back over to GSM your call will drop. That really pissed me off a couple times until tech support told me why and how to fix it.
Dan
I'm not running an open relay. Mail is coming in, sent to my users, with a forged From: address that uses those non-existent addresses @[ourdomain].com. I'm currently working on management about getting a *nix machine in place as a mail gateway so I can do proper filtering to get rid of some of this crap. SPF seems to be the most elegant solution to this particular problem, certainly for our purposes.
Dan