I disagree and strongly. I've heard this excuse too many times, usually from middle management: "We have no idea how to quantify your work, that's why we bill to the hour". Excuses like that are a sure sign that your management has no clue what they're doing.
If you're doing productive work then there is always a metric to measure it. It doesn't matter if your contribution comes in the form of java classes, swf movies or graphics files and in what volume. A good manager always knows what everyone is doing, how they are progressing and how they are performing in relation to their task, skills and potential other duties.
When I ask my manager "how's our project doing?" he can rattle down on each individuals performance and progress, and he will say stuff like "Bob is a bit behind because of personal stuff" or "The new guy is slow but shows promise" or "I don't think the new guy will meet our expectations, but maybe he's just a slow-starter, I'll give him another month".
For a good project manager such assessments are trivial to make. Unfortunately 99% of all project managers I have met were not good, by any metric. I guess that's why many people, like you, think this stuff would be rocket science anyhow and why snakeoil recipe-books about SCRUM, Agile, XP etc. sell like hot-cakes.
I've been telecommuting for the last 2 years (only going to the office when there is a meeting or to oversee hardware deployments) and I can second what you're saying. Not only takes it discipline to get yourself working, it also takes discipline to make yourself *stop* working even when something is not finished, yet.
That can be harder than it may sound but it's absolutely critical in order to maintain a sustainable work/life-balance.
I never really had a problem with the "pressure" you mention but that's probably because I don't normally get assigned tasks that take under a day to finish. My stuff normally takes at least 2-3 days and, well, in case of emergency everybody is expected to work "anytime" anyways.
I'd like to give Znork some credit here. ZFS is really, really nice but it does have some warts and the biggest for many would be that arcane operating system that's dangling off its nutsack. Yes the solaris kernel is great, scales like a champ etc. but the userland and the lack of centralized package management (in 2008, no less!) are bad joke.
If something affects all popular distributions of GNU/Linux, I don't see why that should keep it off the/. front page.
Because it doesn't affect all popular distributions. I'm a regular on our LUG and everytime someone comes up with the "why does my flash crash all the time"-question my first suggestion is to boot an Ubuntu LiveCD and check whether the crashes still happen. Most of the time we don't hear again from these people.
From your ID I can tell that you're long enough on slashdot to not *seriously* complain about the lack of a test-case. This article is not a bug-report. It's just some random kid crying about how cruel the world is to him - and slashdot publishing it for the ad revenue.
Flash-Bashing is still 'in'.
I don't care much for flash either but the problems he describes are most certainly configuration issues with his machine and not related to the plugin. Yes, flash has been bad on linux. It has been outright horrible until around version 7. Today version 9 of the plugin works quite reliably, even on amd64 kernels - as thousands of users can attest.
I'd suggest to the author of this "article" to grab a recent ubuntu livecd and check whether the crashes still appear in that environment. I'm pretty sure the crashes will magically go away once his *other* broken system components (alsa is a favorite culprit) are removed from the equation.
Well, you are right, I was a bit quick with my conclusions. Especially I didn't notice that not all iPhones are affected and that it may be fixed with a soft-update (albeit it's the first time I hear that last one).
Anyways, here in germany the iPhone is licensed by T-Mobile. So at least I wasn't that far off on that one.;-)
What were apple and t-mobile thinking that made them roll out a multimillion dollar product without a friggin' field test? Maybe they had a deadline to meet but I'm quite sure the bill for this blooper will by far dwarf any advantages that they had anticipated. By what I've read on the net it seems like every new iPhone is affected. That means pretty much every new iPhone will be returned... Ouch!
You have obviously never worked on a large scale system where latency matters. Conditional logging is not quite as trivial as you suggest because often the decision about "to log or not to log" is more complex than a simple branch. If your log-level granularity is "ON or OFF" then you will never be able to switch it on in production because the flood bogs down your application. If your granularity is finer than that then you face a bit of decision making (at least a hash lookup) for every log-statement. Yes, that's still cheap but by no means "free" as you suggest. It can make quite a difference under load. Finally you have to consider the case when logging is actually (partially) enabled. That's additional I/O your app has to perform which may or may not significantly change the load profile, depending on what your app does. Guarantee'ing that a log-call will never block can be non-trivial in a multithreaded app and establishing this guarantee comes at a cost of its own.
Thus, your blanket assumption that any given "entire logging infrastructure" will only give or take "a whopping 0.1 CPU-seconds per hour" is... pretty dumb.
Logging directly to a RDBMS (I guess that's what grandparent suggested) is a bad idea in performance critical apps. We generally stream our logs over the net to a central logserver that writes them to files. The idea is to "fire and forget", get rid of the stuff as quick as possible so the app can proceed doing whatever it's supposed to do. Never block on a logging call.
For thorough analysis we may *later* import the logfiles into a RDBMS. This can comfortably be done offline, no need to bog down mission-critical infrastructure...
Re:Establishing de facto (open source) standard ?
on
ECMAScript 4.0 Is Dead
·
· Score: 1
What does the zillionth javascript framework have to do with his (legitimate) request?
Besides sproutcore looks less than impressive, even by javascript metrics. It took ages to load, yet the few available widgets feel sluggish under linux. Oh and ofcourse the layout blows up when changing font-size...
Sounds a bit like marijuana or just like when you're really drunk. In both states it's fairly hard to get upset about something (or well, to get upset about the right things).
Having the "upset blockade" without the other side-effects of the aforementioned drugs does indeed sound scary, though. Although I wonder a bit how you even know what things you "should have been upset" about. Do you realize it after the drug fades?
Ehm. If your bank account can lose money only by someone guessing your password then I'd strongly suggest to switch to a bank that requires TAN authorization for transactions...
I think you missed his point. As I understand it he's (rightfully) complaining that most security questions allow (or even cry for...) an ambigious answer. This is even more of a problem when you have to later re-type the answer into a webform as those are normally not very forgiving wrt variations in syntax or spelling.
Btw stuff like "What is your mothers maiden name" or "What city did you grow up in" does not count as a security question because such info could easily be figured out by an attacker.
Never underestimate human/management stupidity. My ex-employer is currently performing his third outsourcing-experiment for core infrastructure - after the first two (thailand and russia, iirc) failed horribly.
The ratio being (no kidding): "We pay only 1/3 for them, so we can try at least 3 times." Needless to say the damage done by the first two experiments already ate pretty much all potential savings for the next 5 years...
Slashdot Mirror
I disagree and strongly. I've heard this excuse too many times, usually from middle management: "We have no idea how to quantify your work, that's why we bill to the hour".
Excuses like that are a sure sign that your management has no clue what they're doing.
If you're doing productive work then there is always a metric to measure it. It doesn't matter if your contribution comes in the form of java classes, swf movies or graphics files and in what volume. A good manager always knows what everyone is doing, how they are progressing and how they are performing in relation to their task, skills and potential other duties.
When I ask my manager "how's our project doing?" he can rattle down on each individuals performance and progress, and he will say stuff like "Bob is a bit behind because of personal stuff" or "The new guy is slow but shows promise" or "I don't think the new guy will meet our expectations, but maybe he's just a slow-starter, I'll give him another month".
For a good project manager such assessments are trivial to make. Unfortunately 99% of all project managers I have met were not good, by any metric. I guess that's why many people, like you, think this stuff would be rocket science anyhow and why snakeoil recipe-books about SCRUM, Agile, XP etc. sell like hot-cakes.
I've been telecommuting for the last 2 years (only going to the office when there is a meeting or to oversee hardware deployments) and I can second what you're saying. Not only takes it discipline to get yourself working, it also takes discipline to make yourself *stop* working even when something is not finished, yet.
That can be harder than it may sound but it's absolutely critical in order to maintain a sustainable work/life-balance.
I never really had a problem with the "pressure" you mention but that's probably because I don't normally get assigned tasks that take under a day to finish. My stuff normally takes at least 2-3 days and, well, in case of emergency everybody is expected to work "anytime" anyways.
Ah that's obvious, for the groove minister!
I'd like to give Znork some credit here.
ZFS is really, really nice but it does have some warts and the biggest for many would be that arcane operating system that's dangling off its nutsack. Yes the solaris kernel is great, scales like a champ etc. but the userland and the lack of centralized package management (in 2008, no less!) are bad joke.
...with a tank?
Thanks for taking the time to dissect this idiot.
Well, it's definately more of an invention than the mobility pranks that
other kids come up with in their idle time.
And here's your instrumentals (starting from 5:15) if you really want to sing it.
Hm. That comic was about as exciting as watching bubbles.
Obvious much? Guess why it's called the kernel and not, say, the fluffy marshmallow.
Because it doesn't affect all popular distributions. I'm a regular on our LUG and everytime someone comes up with the "why does my flash crash all the time"-question my first suggestion is to boot an Ubuntu LiveCD and check whether the crashes still happen. Most of the time we don't hear again from these people.
From your ID I can tell that you're long enough on slashdot to not *seriously* complain about the lack of a test-case.
This article is not a bug-report. It's just some random kid crying about how cruel the world is to him - and slashdot publishing it for the ad revenue.
Flash-Bashing is still 'in'.
I don't care much for flash either but the problems he describes are most certainly configuration issues with his machine and not related to the plugin. Yes, flash has been bad on linux. It has been outright horrible until around version 7. Today version 9 of the plugin works quite reliably, even on amd64 kernels - as thousands of users can attest.
I'd suggest to the author of this "article" to grab a recent ubuntu livecd and check whether the crashes still appear in that environment. I'm pretty sure the crashes will magically go away once his *other* broken system components (alsa is a favorite culprit) are removed from the equation.
Well, you are right, I was a bit quick with my conclusions. Especially I didn't notice that not all iPhones are affected and that it may be fixed with a soft-update (albeit it's the first time I hear that last one).
Anyways, here in germany the iPhone is licensed by T-Mobile. So at least I wasn't that far off on that one. ;-)
Also it's a hard case of "epic QA failure".
What were apple and t-mobile thinking that made them roll out a multimillion dollar product without a friggin' field test? Maybe they had a deadline to meet but I'm quite sure the bill for this blooper will by far dwarf any advantages that they had anticipated. By what I've read on the net it seems like every new iPhone is affected. That means pretty much every new iPhone will be returned... Ouch!
You have obviously never worked on a large scale system where latency matters.
Conditional logging is not quite as trivial as you suggest because often the decision about "to log or not to log" is more complex than a simple branch. If your log-level granularity is "ON or OFF" then you will never be able to switch it on in production because the flood bogs down your application. If your granularity is finer than that then you face a bit of decision making (at least a hash lookup) for every log-statement. Yes, that's still cheap but by no means "free" as you suggest. It can make quite a difference under load.
Finally you have to consider the case when logging is actually (partially) enabled. That's additional I/O your app has to perform which may or may not significantly change the load profile, depending on what your app does. Guarantee'ing that a log-call will never block can be non-trivial in a multithreaded app and establishing this guarantee comes at a cost of its own.
Thus, your blanket assumption that any given "entire logging infrastructure" will only give or take "a whopping 0.1 CPU-seconds per hour" is... pretty dumb.
Logging directly to a RDBMS (I guess that's what grandparent suggested) is a bad idea in performance critical apps.
We generally stream our logs over the net to a central logserver that writes them to files. The idea is to "fire and forget", get rid of the stuff as quick as possible so the app can proceed doing whatever it's supposed to do. Never block on a logging call.
For thorough analysis we may *later* import the logfiles into a RDBMS. This can comfortably be done offline, no need to bog down mission-critical infrastructure...
What does the zillionth javascript framework have to do with his (legitimate) request?
Besides sproutcore looks less than impressive, even by javascript metrics. It took ages to load, yet the few available widgets feel sluggish under linux. Oh and ofcourse the layout blows up when changing font-size...
Sounds a bit like marijuana or just like when you're really drunk. In both states it's fairly hard to get upset about something (or well, to get upset about the right things).
Having the "upset blockade" without the other side-effects of the aforementioned drugs does indeed sound scary, though. Although I wonder a bit how you even know what things you "should have been upset" about. Do you realize it after the drug fades?
Well, you can always trade in lifetime to recover more of those precious gigabytes...
But I suggest you simply do what everybody does: Buy a bigger disk and stop whining. Or live with the trade-off you made by going SSD.
Tinfoil hat much?
Every bigger ad agency (google) can do the same thing.
Yeah, bring on the violence!
A few good games, are you kidding?
Sega has taken video-game violence to a whole new level.
Ehm. If your bank account can lose money only by someone guessing your password then I'd strongly suggest to switch to a bank that requires TAN authorization for transactions...
I think you missed his point.
As I understand it he's (rightfully) complaining that most security questions allow (or even cry for...) an ambigious answer.
This is even more of a problem when you have to later re-type the answer into a webform as those are normally not very forgiving wrt variations in syntax or spelling.
Btw stuff like "What is your mothers maiden name" or "What city did you grow up in" does not count as a security question because such info could easily be figured out by an attacker.
Never underestimate human/management stupidity.
My ex-employer is currently performing his third outsourcing-experiment for core infrastructure - after the first two (thailand and russia, iirc) failed horribly.
The ratio being (no kidding): "We pay only 1/3 for them, so we can try at least 3 times."
Needless to say the damage done by the first two experiments already ate pretty much all potential savings for the next 5 years...