Comment AKA (Score 1) 391
... opposed by cable and telephone companies that fear it will curb Internet growth and stifle payback on network investment.
Snooping for ad revenues and obscene profit margins
... opposed by cable and telephone companies that fear it will curb Internet growth and stifle payback on network investment.
Snooping for ad revenues and obscene profit margins
fuck capitalism.
It has nothing to do with capitalism. It has everything to do with unregulated corporate greed. They are NOT the same things. The same kind of greed was seen very prominently in countries that called themselves Socialist and even Communist. So don't blame "capitalism" for it. It's cronyism, plain and simple.
And this is almost laughably wrong:
The rules, which have not yet been released, are opposed by cable and telephone companies that fear it will curb Internet growth and stifle payback on network investment.
I call BS. They don't "fear" it will do anything of the kind. What they fear is that it will put a stop to their monopolistic control, and monopolistic prices, and end their ability to pocket tax money given them for infrastructure.
I mean this literally: you can hardly believe a word they say anymore.
Anything you can do on mars, robots can do better. already.
Anything? Says you, your wife, or the battery-powered robot in her bed-side table?
That reading would seem to permit the Feds to override any and all State laws against political subdivisions doing anything.
Why?
The Constitution very clearly gives Congress the authority to regulate interstate commerce. And it is pretty much indisputable that the Internet involves interstate commerce.
I, for one, think Congress has tried to stretch the "interstate commerce" excuse way too far, in order to regulate many things that are not directly involved with interstate commerce. Like growing marijuana.
But the internet is not one of those things.
Were female models more comfortable with you than they would be with a male photographer?
I didn't hang with other photographers, and the models I worked with were not already-known professionals, so I don't have any way to make a comparison.
This is no different that what submariners experience - with no natural light, they move to an 18 hour day (6 on 12 off). Contrast this to driving across the ocean in a ship and traversing the various time zone.
Also, experiments done decades ago, in caves with no day-night cycle, led to longer awake cycles much like those. So I really don't see what the problem is here.
Naturally, it takes time to adjust. Shift-work studies have shown that it takes the body AT LEAST 30 days to fully adjust to a new schedule, some people as long as 60. Interrupt it before then and you end up with problems.
Yep, you see this all the time in the iOS development community too. People coding my sticking together 100 slightly incompatible 3rd party libraries, and writing a bunch of glue code. Then hitting problems and responding to help solving them with "we can't do that, we're required to do it this way because the 3rd party library does it that way".
Exactly. I don't mind including a good tool that does its job well and leaves everything else alone. But I've run across at least 2 very sad "syndromes" that add-ons sometimes cause:
The first syndrome is represented by libraries that take over everything and unnecessarily restrict your otherwise legitimate actions, because they ASSUME everything will be done with or through them. 2 great examples come to mind from the Ruby world: Formtastic, and Devise.
I dumped Formtastic because it insisted on generating its own <ul> for the form, and <li> tags for all the elements, which prevented you from laying out your forms your own way. Trying to wrap elements in named or classed <div>s so you could do your own layout resulted in invalid HTML. Maybe Formtastic has improved since then, I don't know. I discussed this problem with the author, and his response was "Why would you want to do that?" Which just illustrates my point.
Devise is way too intrusive and makes too many assumptions. Besides being based around unproven Bcrypt (which has never been fully security audited), it tries to force you to do everything else its way, too. It may be "customizable", but in my experience that's far more trouble than it's worth. My opinion is that most people who use Devise do so because they don't understand how to do it themselves.
The second syndrome is "copy and paste development". This irritates me to no end. "Why don't we just use X? It already does that." "Well, because it's like shooting an ant with a cannon. A cannon that also wants to wash your dishes."
The right tool for the right job. Often, especially for small jobs, it's vastly preferable to roll your own tools, and do it your way.
Interesting, I didn't know that if someone had a beautiful body they had a non-functional brain.
That's one of the advantages of having a beautiful body.
Unfortunately, one disadvantage is usually the math: Beauty x Brains = Constant
No, it's not beta. Beta's a lot worse (think full of AJAX).
"Oh my God; it's full of AJAX !" was the original line in 2010, but they eventually changed it to "stars !"
You mean photocopied or something having to do with a registered trademark? Why not simply "Copied".
Then something changes and blows the estimates out of the water. But the MBA's think since only one line in the spec changed, the schedule should stay the same.
And that's when you re-negotiate, or quit.
From my experience, it's easy to make bad estimates because bad estimates are easy to make. If it's a big project, take your worst possible guess, and multiply by 1.5.
One of the biggest reasons bad estimates are so easy to make, is that the stakeholders "forget" to include too many of the details. And even, sometimes, some of the big essential features. It's debatable how many of these things are really "forgotten", versus not known or just intentionally left out to lower the estimate.
Therefore, I go about it this way:
I write out clearly what the specs are. Often this is just a repeat of the stakeholder's own specs. I estimate each major "feature" in the specs.
My standard contract states that this is only an estimate, based on the written scope of work just described. If at any point it looks like the work will take more than 10% over the estimate, it is time to examine why and the terms must be re-negotiated.
If any significant changes or additions are made to the scope of work, the terms must be re-negotiated.
These stipulations make sure everybody is talking, and if anything goes over estimate, everybody knows why. It also makes sure that if they add more work, I get more money.
I have a third stipulation I put in every contract: single point of contact. The stakeholder(s) must appoint one person, and one person only, who is to give me instructions and discuss the specifications. Nobody else, even the CEO, is allowed to do that.
I insist on these. So far, I have not had anybody turn me down because they thought the terms were unreasonable. That last clause keeps me from getting caught between conflicting instructions from different people. Other than that one, these are SOP for many engineering contracts. I just borrowed from those.
Unfortunately, regulating greed doesn't work. You have to fix the problem. You have to have a society of people that aren't greedy. Good luck with that!
It worked pretty well with telephones for 40-50 years. Granted, significant corruption was leaking in toward the end, but for a very long time the ill effects of monolithic monopoly were kept at bay, while we kept the advantages (i.e., world's best interoperability, reasonable rates for their day).
During that time, in some countries in Europe which allowed competition in the market, you couldn't call the neighbor on one side because he was using a different phone company, and even the respective voltages were not compatible. And you couldn't call the other neighbor on the other side, because she was on yet a different company. And there were 3 times as many wires on the poles.
Those who can, do; those who can't, write. Those who can't write work for the Bell Labs Record.