And to be honest, I'm not sure I really want to read any attempts to do so. Why can't they just let a great series be a great series, instead of trying to extend it?
If that thought were applied to movies, we'd have never had DS9 or the JJ Abrams Star Trek movie. Why is it OK for TV and movies but not novels? It's a common thought and I don't get it.
Because for any sufficient volume of processing you're going to be spending many times more using these cloud services than running your own server
And running your own server means keeping an admin guy on staff. It's no more stupid than throwing your box into a colo and having it managed by colo admins or purchasing a virt from a webhost. If you're running a small business, its stupid to host your own these days. A large business has the benefit of economies of scale--small businesses do not.
They'd never get a judge to sign a lien or wage garnishment unless the SSN, name, and birthdate matched. Not to mention signatures on signed documents.
Re: author of the blog post you pasted. That author reeked of pomposity and arrogance by assuming only those Americans wouldn't understand the phrase or that it's obvious to anyone but an American.
In addition to the other responses... there's also the reason of fabrication defects. The probability of a defect is constant for a 1cm x 1cm area so when the CPU area goes up the number of defects goes up. You only need 1 defect to trash the entire chip, so there's an financial need to achieve a defect rate per CPU as close to 0 as possible.
Brainstorming a little bit... some advantages could be:
Creating a distinct unambiguous brand name. It's harder to do that if you're piggy backing on Firefox which has it's own brand name.
Andreessen's position in the industry brings notability so it'll be newsworthy (news articles = free advertising). His expertise is with browsers, so I imagine leveraging his name is more congruent with a new browser rather than a new browser plugin.
They believe a plugin is a harder sell because there could be less perceived value in a product that sports conceptual features described in the language of business-speak. Language such as social networking, advertisement engine, productivity tools, website integration, bridge software, blah blah blah; as opposed to Flash which has concrete, visible animation features. Everyone knows what a browser is, so it's conceptually more concrete. It has an installation program, desktop icon, application window, and title bar.
Maybe they feel the concept of "browser" is a hot topic at the moment (due to Firefox and Chrome) and they want to ride the wave. "plugin" isn't so desirable anymore because it recalls the legacy of the 1990's: implying old, "been there, done that", ho-hum, ancient.
Maybe they feel owning their own browser platform lends more technical credibility over owning a browser plugin because the technical challenge is greater. Technical credibility could translate to bu$ine$$ credibility.
Maybe they want control of proprietary source code, so it'll obfuscate the plan to spam the hell out---err, I mean--provide useful related links to web queries.
Maybe they want full control of the browser in order to make good on business partner contracts. It's harder to make those guarantees when disinterested 3rd party plugins can disable or intercept your plugin with very little effort.
Maybe they want control of the installation base in order to directly sell plugin access or communication channels--as opposed to rev sharing with 3rd parties (such as google).
Maybe they plan to build and sell in order to be accumulated by another business. They'll need a flagship product and user database to do that.
For customer and email data, seed it with false information that you can intercept. This will tell you if anyone has stolen your data and is now using it. You should periodically add new seeds and store a date with it so you can pin down an approximate time period should someone email your entire list. Keep your seed source code and data outside of your production source code and database and away from the admins.
Sounds like you're using an honor system to me.. that would be abused pretty heavily here. There's already some abuse with taking sick days and not reporting them. Some managers forget or don't keep up with who took what day off.
It's too complicated from an HR viewpoint. It's easier to group it all into one "benefits package" and align everything to the tax/calendar year because other benefits (such as 401k/medical/life/disability/payroll/withholding) are already aligned to quarterly windows. Those are often managed by 3rd parties so aren't readily changeable. The grouping and alignment of all your benefits is considerably easier to manage compared to benefits having different schedules, which may occur once you start making special cases. Since HR is always cost conscious (probably due to their usual integration with finance) they will err toward taking the easier (less costly) path.
Secondly, I think your suggestion would hurt more than help for many IT oriented businesses because it doesn't matter when vacation time starts accruing, employees will still conserve them for the holidays. They will roll them over from previous cycles if necessary. Holidays are significant national events so you can expect vacations to converge regardless of their accrual schedule. It's also easier to run a business with a constant (most vacations taken in Q4) rather than a variable (vacations taken whenever).
It's better to simply accept this and plan for November and December being slow development months (although hectic for POS retail (separate topic)). Many companies go into "lights on" mode during this period by instituting code freezes and doing next year's planning, budgeting, and design analysis. (There's not much else to do if you're not making production changes). It's a natural fit with the calendar year and holiday schedule.
For businesses heavily reliant on operations the end of Q4 truly sucks. There is no perfect solution when everyone is vying to take vacations around the same time, so a few must lose.
Sick time is distinguished from vacation time (in the US) to fairly manage unplanned and planned time off. If it was all sick time, then taking 3 weeks off with very little notice would disrupt business planning. If it was all vacation time, then time off from sickness would be useless if you needed to report it N number days in advance. There are exceptions. A few US companies only have PTO (paid time off) and require management approval before taking above some value N number of days.
Oh.. and as you mentioned, you would be stupid not to use it up throughout the year because if you wait until November (holiday season), you'll most likely not be able to use it all, particularly if you don't have seniority or you're on pager.
Side note. Many US companies have moved to an accrual method of doling out your vacation/sick/PTO days. For example, in January you may start out at 3 days and accrue 1 or 2 days per month. They do this to avoid paying you out your full year's worth of vacation time should you quit or be terminated, because at any given point in time between January and November, your accrued vacation time will be much lower than your maximum achievable on December 1st.
What about a "that bug is a feature" type of bug? What if we can't agree on categorizing its severity level? What if the bug affects 0.01% of the population and not worth fixing? What if the bug only appears occasionally when executing on runtime library 1.0, but never on 2.0? What if it works on a clean install but not when driver Y is installed? What if the bug is due to the user not keeping their OS up to date? What if the issue stems from data corruption? What if your code is script run inside of a 3rd party engine which you know might have a bug?
How did I fail to take in account of the shades of grey? I specifically mentioned the existence of ambiguity and that #2 was a sliding scale (synonymous with "shades of grey").
I did not eliminate #2 arbitrarily. I eliminated it because it evaluates to a meaningless answer. Also, it doesn't matter if our scale is fractional or not. I can change Max to infinity and still achieve an infinite number of possibilities even with your rule of "integers only". By understanding all the possibilities and their meanings, we have expanded our ability to reason. Avoiding usage of the #2 case does not mean we forget ambiguity exists in our language. It just makes our communication clear and more effective.
It's understandable different people have different work habits but which is the worst solution? Sending off your paper to a validation service which archives without your consent or doing the work in a monitored environment such as a classroom?
Out of curiosity. How do (or will) you handle writing lengthy documents at work in cubicle-land? Many times, workplace environments are noisy and you'll find yourself frequently interrupted by emails, phone calls, and co-workers with questions and whatnot.
There are 3 combinations right? Let's label care level as C, where Min is 0, and Max is 10. Then Min <= C <= Max of 10. The following would hold true.
I could not care less. C == 0
I could care less, or, I could care more. Min < C < Max
I could not care more. C == Max
With #1 and #3, the statement provides specific and provide useful information. With #2, the statement is unspecific and could result in an infinite number of values for C. #2 isn't very useful in that it communicates an ambiguous thought. Is C close to Min? Close to Max? In the middle? Who knows. Since we strive to communicate effectively, the proper course of action to take when presented with such ambiguity is to discard it. It's by that reasoning I invalidate #2.
Slashdot Mirror
I see the hair replacement industry picking this up and driving it.
Slashdotters criticising things that were financially very successful. I'm shocked. No wait, I'm not. I sense jealousy.
Bull. It was the best in the series. The lense flares were overused but that does not invalidate it was a very well crafted movie.
If that thought were applied to movies, we'd have never had DS9 or the JJ Abrams Star Trek movie. Why is it OK for TV and movies but not novels? It's a common thought and I don't get it.
And running your own server means keeping an admin guy on staff. It's no more stupid than throwing your box into a colo and having it managed by colo admins or purchasing a virt from a webhost. If you're running a small business, its stupid to host your own these days. A large business has the benefit of economies of scale--small businesses do not.
What about installation and software setup? How does 1-3 days beat launching a node in 5-15 minutes?
Woosh...
They'd never get a judge to sign a lien or wage garnishment unless the SSN, name, and birthdate matched. Not to mention signatures on signed documents.
Is president of the United States considered a government employee? Cuz... that totally messes up your comment if so.
I suppose the light gun is better for FPS games with controlled movement along a path.. and not so much for games with full freedom of movement.
I don't think the mouse is superior to the light gun for aiming/pointing. It's just too bad the light gun isn't very common except for with coin-ops.
Re: author of the blog post you pasted. That author reeked of pomposity and arrogance by assuming only those Americans wouldn't understand the phrase or that it's obvious to anyone but an American.
In addition to the other responses... there's also the reason of fabrication defects. The probability of a defect is constant for a 1cm x 1cm area so when the CPU area goes up the number of defects goes up. You only need 1 defect to trash the entire chip, so there's an financial need to achieve a defect rate per CPU as close to 0 as possible.
For customer and email data, seed it with false information that you can intercept. This will tell you if anyone has stolen your data and is now using it. You should periodically add new seeds and store a date with it so you can pin down an approximate time period should someone email your entire list. Keep your seed source code and data outside of your production source code and database and away from the admins.
Sounds like you're using an honor system to me.. that would be abused pretty heavily here. There's already some abuse with taking sick days and not reporting them. Some managers forget or don't keep up with who took what day off.
It's too complicated from an HR viewpoint. It's easier to group it all into one "benefits package" and align everything to the tax/calendar year because other benefits (such as 401k/medical/life/disability/payroll/withholding) are already aligned to quarterly windows. Those are often managed by 3rd parties so aren't readily changeable. The grouping and alignment of all your benefits is considerably easier to manage compared to benefits having different schedules, which may occur once you start making special cases. Since HR is always cost conscious (probably due to their usual integration with finance) they will err toward taking the easier (less costly) path.
Secondly, I think your suggestion would hurt more than help for many IT oriented businesses because it doesn't matter when vacation time starts accruing, employees will still conserve them for the holidays. They will roll them over from previous cycles if necessary. Holidays are significant national events so you can expect vacations to converge regardless of their accrual schedule. It's also easier to run a business with a constant (most vacations taken in Q4) rather than a variable (vacations taken whenever).
It's better to simply accept this and plan for November and December being slow development months (although hectic for POS retail (separate topic)). Many companies go into "lights on" mode during this period by instituting code freezes and doing next year's planning, budgeting, and design analysis. (There's not much else to do if you're not making production changes). It's a natural fit with the calendar year and holiday schedule.
For businesses heavily reliant on operations the end of Q4 truly sucks. There is no perfect solution when everyone is vying to take vacations around the same time, so a few must lose.
Sick time is distinguished from vacation time (in the US) to fairly manage unplanned and planned time off. If it was all sick time, then taking 3 weeks off with very little notice would disrupt business planning. If it was all vacation time, then time off from sickness would be useless if you needed to report it N number days in advance. There are exceptions. A few US companies only have PTO (paid time off) and require management approval before taking above some value N number of days.
Oh.. and as you mentioned, you would be stupid not to use it up throughout the year because if you wait until November (holiday season), you'll most likely not be able to use it all, particularly if you don't have seniority or you're on pager.
Side note. Many US companies have moved to an accrual method of doling out your vacation/sick/PTO days. For example, in January you may start out at 3 days and accrue 1 or 2 days per month. They do this to avoid paying you out your full year's worth of vacation time should you quit or be terminated, because at any given point in time between January and November, your accrued vacation time will be much lower than your maximum achievable on December 1st.
What about a "that bug is a feature" type of bug? What if we can't agree on categorizing its severity level? What if the bug affects 0.01% of the population and not worth fixing? What if the bug only appears occasionally when executing on runtime library 1.0, but never on 2.0? What if it works on a clean install but not when driver Y is installed? What if the bug is due to the user not keeping their OS up to date? What if the issue stems from data corruption? What if your code is script run inside of a 3rd party engine which you know might have a bug?
Not all bugs are solvable.
Why? Why not? I suspect converting to JS could yield some pretty good compression. I may try out some tests this weekend.
It might be interesting to setup an AJAX movie feed with streaming SVG data. Just have to preprocess the MPG to SVG.
How did I fail to take in account of the shades of grey? I specifically mentioned the existence of ambiguity and that #2 was a sliding scale (synonymous with "shades of grey").
I did not eliminate #2 arbitrarily. I eliminated it because it evaluates to a meaningless answer. Also, it doesn't matter if our scale is fractional or not. I can change Max to infinity and still achieve an infinite number of possibilities even with your rule of "integers only". By understanding all the possibilities and their meanings, we have expanded our ability to reason. Avoiding usage of the #2 case does not mean we forget ambiguity exists in our language. It just makes our communication clear and more effective.
It's understandable different people have different work habits but which is the worst solution? Sending off your paper to a validation service which archives without your consent or doing the work in a monitored environment such as a classroom? Out of curiosity. How do (or will) you handle writing lengthy documents at work in cubicle-land? Many times, workplace environments are noisy and you'll find yourself frequently interrupted by emails, phone calls, and co-workers with questions and whatnot.
There are 3 combinations right? Let's label care level as C, where Min is 0, and Max is 10. Then Min <= C <= Max of 10. The following would hold true.
With #1 and #3, the statement provides specific and provide useful information. With #2, the statement is unspecific and could result in an infinite number of values for C. #2 isn't very useful in that it communicates an ambiguous thought. Is C close to Min? Close to Max? In the middle? Who knows. Since we strive to communicate effectively, the proper course of action to take when presented with such ambiguity is to discard it. It's by that reasoning I invalidate #2.