"People don't like to be meddled with. We tell them what to do, what to think, don't run, don't walk. We're in their homes and in their heads and we haven't the right. We're meddlesome." -- River Tam
Go ahead, turn some knobs. See how it affects the lives of complete strangers.
...forced DUI checkpoints and they DO draw blood if they want to...
In Texas, they have to get a court issued warrant to draw blood. It is considered, as I understand it, by our supreme court as a violent act - extracting part of your body against your will.
Is it different in any other states? Can the officer on the scene make that determination? Links?
Something else to rage about today... :
Let's remember that originally the point of the GPL was to allow people to share source freely, so that you could pass your work on and be assured that other users could pass it on too. It prevented restrictions on the sharing of something you created. It made your work open and free.
If I understand this right, and GPLv3 requires the allowance of "modifications in place", the GPLv3 is going far beyond that. It's no longer about keeping code open and free, it's forcing others to make their property open and free. It's no longer about sharing your work, it's about how your work is used.
Regardless of how you feel about "tivoization" -- personally I hate it -- this is telling someone else what to do with what they created. That's not making a statement about your own property, it's making a statement about somebody else's.
I'm a developer. Developers have the right and justification to release software under whatever license they choose! If a dev wants to restrict against "Tivoization", that's fine.
But let's not kid ourselves that "modifications in place" is about sharing software. This is going much further, and people with an interest in engineering things for the world to benefit from and making a living in the process have a very well qualified criticism.
http://www.qdb.us/305324 <Pomax> 20 years from now, someone is going to have the radical idea to give users access to the underlying OS, rather than to the browser API, and he will be heralded a revolutionary. <Pomax> All manner of programming languages will pop up that work outside "the browser", giving access to "offline" applications, storing files in "user space", even perhaps running in something called "kernel mode". <Pomax> It'll be a brave new world. <Mirell> It's scary that's believable.
You're spot on. All it takes is one $0.02 sticky note with a Mult1pl3.R3str1c71Ons.En4rced password written on it to make all this huff and bluster worthless in most IT environments.
People seem to forget that Users use computers. Not Security Nuts. Not IT staff.
Real security accounts for social factors. The reason the Sup3r!Pa55w0rd policy fails is the same reason the easiest way into a network is often social engineering. Users. Security is not purely technological problem.
Security starts with taking your weakest link into account. Hint: It isn't that your "10 character minimum, 2 character subset" requirement is too weak.
Employees should backup their own data. If they are uncomfortable with the possibility of Employer wiping their personal phone, then they should not connect their personal phone to work email.
This is stupid.
There should absolutely, absolutely be a way to wipe a corporate account off a phone. That data is the property of the corporation.
But wiping everything is just inane. There is absolutely no reason to wipe pictures, personal contacts, emails, etc. This is software we're talking about. Just wipe the account(s) in question.
The only thinkable reason to wipe data outside of the corporate account is "you could have copied work content elsewhere," and that argument applies no more to phones than to personal computers. Hell, it applies to printed material too. Had any former employers snooping through your house lately?
No, the onus is on the corporation to restrict dissemination of corporate data if the risks are too high. Allowing a remote account wipe is a luxury afforded by software, not a corporate right over personal property.
Respectfully, I believe you're going down a bad road. For a small application, and a developer who isn't asleep at the wheel, what you're suggesting can work OK; I imagine it hasn't been a problem for you.
Generally, for everything else, it tends to blow up down the road. And even for smaller projects, the benefits of keeping your logic out of the DB (faster, cleaner, clearer, easier to learn, easier to update) are significant.
I sincerely want to make an effort to be useful to folks who may not have worked with larger projects before. Please take this post in that spirit. It's a long, and I hope informative, post.
Make your code's intent clear... alternatively, write logic in the right context The biggest problem is code intent and flow control. Databases model data, GUIs model user actions, but neither necessarily model business logic. You've got business logic code for that -- like your permissions handling.
Code has a logic-centric view. Databases have a data-centric view. If you write logic in the DB, you're abstracting what you're writing from what you're actually trying to accomplish.
Error handling is a great example for flow control. Trapping an error in the DB, correctly identifying the problem and bubbling it up in a user-appropriate way in a clean fashion, as you said, is difficult.
Keep your code together Another big problem is finding all the right code. For a newbie or a dev who hasn't looked at a bit of code in 6 months, this is very important. Breaking your code up into different buckets based on what data it modifies makes your logic - your flow - hard to follow for anyone who isn't intimately familiar with the project.
Consider two implementations for a feature:
1) Application code triggers an update to three tables. A bunch of magic spread across several triggers on those three different tables and written in (depending on your implementation) three different schema files, or one huge file with your entire schema, updates three additional tables. E.G.: "most complex updates are performed using triggers and rules"
2) One function in one file that, in a transaction, updates six tables.
Which is easier to follow? From which implementation can you get a clear vision of the intent of the code? Which is easier to skim? If a new developer looks at your code, in which implementation is he more likely to miss something the feature touches?
Don't make interoperability harder If you push logic into your DB, interoperability becomes harder, not easier. Before, you had just data, and two different applications could use it differently and have different requirements -- as long as what they did was consistent with the data model (your schema).
Now, with logic in the DB, anyone wanting to share your data has to work around your triggers, or co-opt them, or write entirely new triggers, procedures, and generally muck up your application to accomplish their goals.
Keep your platform flexible Pushing logic into the DB, you may have made it easier to switch languages (although you still have a bunch of "front end" code you'd have to convert/maintain), but now it is much harder to switch databases. What was once merely data is now jumbled up with your application. If Oracle, MSSQL, etc. becomes a necessity, you're not just switching databases, you'll likely be refactoring significant chunks of your app.
Most business needs won't demand you switch languages (worst case, cross-compile or use IPC). Some business needs will demand you switch databases -- my company is now porting our app to MSSQL.
Your database is likely your bottleneck In my experience, the first serious scalability problems most apps encounter are in the database. And the solution is always "more hardware." Beefier machines.
The problem wasn't that the databse was used in a wrong way.
While the database platform may have been a problem, the first, biggest problem wasn't the hardware. It was (bolded for effect): business logic does not belong in your DB, excepting a handful of cases.
I wouldn't normally have replied -- I agree with your point about hardware -- but this deserves to be underscored because so many people fundamentally do not get it.
I work for a company that was just bought out. Our new parent company develops a well known (in its industry) enterprise desktop application. The entirety of their business logic is written in the DB.
It's a maintenance nightmare, difficult to integrate with outside systems, and the system does not scale. Scalability is kicking their ass... because they can't.
Our company spends much less on hardware (and software, cheers for PostgreSQL), and our application is a billion times easier to develop and maintain. We use triggers - but only a handful.
People develop middle layers for a reason. Better code organization and flow control, much, much better speed, scalability, and flexibility.
Use a DB for what it's good at (ACID, data integrity).
save the time and other expenses of a database or key-value store lookup of a session id on every request.
So you save time on a cache/DB lookup by doing crypto processing instead... after which your web application will begin processing the user's request... in most cases querying the database, updating user history, etc.
This seems to me like missing the forest for the trees.
Doing a hash lookup on your cached session is near constant time, avoids security holes introduced by sensitive data client-side, and avoids stacking session data on top of *every request* to the webserver.
That's not even tackling the more serious issue of trusting a user ID from the client without a password because "it's encrypted".
Heh. I live in Texas, one of the few "deregulated" electricity markets in the US.
Our local power lines are owned and maintained by regulated monopolies which set prices per area for monthly maintenance fees.
Power companies then contract with the local infrastructure owner to provide power to the grid. And as a homeowner, I choose which power company I give money to; I pay them for how much electricity I use from the grid, and they generate the electricity. I also pay the maintenance fee passed from the local owner through my power company.
When I chose a power company, I was able to look up JD Power reviews and pick the best company. I had a choice.
It might be worth clarifying: Perl is great to learn, but terrible when you work on code written by people who don't think like you do.
Perl code can be simple, straightforward, very easy to pick up and hit the ground running. It's when you start coding with other programmers that it becomes painful.
The problem resolving this issue in the language design is that people will code they way they think, regardless of your restrictions. What happens when you put a C developer in a Java shop? Instead of writing beautiful, flowing OO code that glows with elegance, they'll write clunky, low-level functional code that steps through their thought process procedurally.
Ditto if you put a Java developer in the world of C. They'll prefer to write large data structures and significantly abstract their code, which will drive a lot of C developers nuts.
My point is, I think the result of requiring a programmer to jump through language hoops often means the resulting code is not only written in a different style, it's now obfuscated further because the programmer dodged your language hoops to do it.
--
I will say, however, that some Perl programmers happen to really love their esoteric, obfuscated language tricks, things like this. I definitely see what is being accomplished -- implicit but short code is often easier to skim and understand than long and explicit where you lose the meaning -- but I think Perl hackers tend to take this much too far.
You fight for this nonsense, thinking that it restricts big corporations. It does....just like everyone else. Including, and *especially*, newcomers.
Who does it really affect more? The company with a professional staffed legal team, entire departments dedicated to training, procedure, and lots of liquid assets to cope?
Or the little guy?
Spend some time thinking before you "shoot the buy guy to make things even." You're aiming at everyone.
The most important axiom in regards to this topic, as I've always said, is:
"Good defaults, lots of options."
Users need good defaults that allow them to get going quickly and that allow them to interoperate with other users and software. Users also need access to options that break compatibility but allow flexibility (such as nonstandard window managers and apps). The user turns on options as his/her own risk; this is how it should be. This is not an either-or situation, unfortunately most people don't recognize this.
Emphasizing this axiom when designing software will balance your software between normal users and people who like to customize their computing environments. You CAN keep both crowds happy; power users don't mind seeing a healthy set of options and newbies won't ever bother, they'll use the software regardless. Applying intelligent organization is the filling that makes this work.
That all said, there is a LOT to like about Linux, the free aspect -- as in both beer and speech -- being a huge part of that.
Still, as big of a Linux nut as I am, they have a long way to go before Linux becomes useful on the desktop without someone around to support it. The flipside of what I'm saying is that people with a geek in the family or companies with a competent IT department can use it wonderfully.
I imagine they took out the whole "Hell" storyline because it's just cheesy and they need to sell it to the masses to make money.
That said, I would advocate doing something like Event Horizon - describe "Hell" just like it is, a dimension of chaos, blood, torture, mutilation, etc. etc. but never call it Hell. It's still creepy and can follow the generic Doom storyline, but sell-able IMO.
I can also understand why it's not just one marine and why Sarge (played by The Rock) is leading a team -- makes for more characters, character development, and, well, a movie instead of a video game.
But I do not understand for the life of me why the whole Mars City thing had to be abandoned. I honestly think that a slightly modified Doom 3 plot (don't call it Hell, maybe remove a certain scientist from the plot, Sarge leads a team of Marines) would work very well. Especially if they start it out the same, but perhaps draw the intro out a bit.
But what do I know? I'm sure it's too much to hope for that what I've heard is wrong.
What kind of company prevents a very competent employee from moving up in the ranks?
It's called career development, and managers with a clue and respect for their underlings take it upon themselves to HELP promote folks. This means giving raises, offering new opportunities, etc. After handling grunt work for a while, you're given control of a project with oversight. Then you're given control of a project with final approval resting with someone else. Then you get control of a project. Then you become official "management".
The process is gradual, thus negates the common "a degree means you stand a higher chance of being management capable."
I'm sorry, it's quite possible I just have my head up my arse this evening, but in anything but a huge company with lots of red tape, why on God's green earth would you not be able to move into management without a degree?
"So wait, Kyoto doesn't go far enough. Therefore we shouldn't sign it. I mean, its a start, right?"
Ever have a day at work where your boss wants to do something half-assed and you know if your company goes that route, doing "just enough", you'll be stuck with the bill of fixing it in a year when it becomes insufficient?
I know this doesn't relate to a lot of the Slashdotters who don't have jobs but love to comment on the Real World.
America isn't about to legislate something that gives others an advantage in industry, especially with the half-assed solutions the "international community" puts through. Likely we'd get stuck with the bad end of the stick for a few decades until enough of the centrist population started rabbling about the environment again.
I'm all in favor of protecting the environment, it's one of the few things in this world I see as public property, but given the apathetic and self-interested nature of every civilized nation on this planet (especially the US, France, Germany, China, Russia, et. al.), if we're going to do this let's do it right across the board.
Arguing for something that forces companies to behave more like companies for their own sake has no merit. It is the freedom of the human beings who own and run those companies to make their own mistakes.
Now passing treaties and such to help the environment is another issue which I generally support, but you must make the distinction. The government isn't here to tell companies how to run themselves, and though this treaty in some cases may make companies more profitable long-term, that is at best a nice side-effect of the treaty but not a founding reason to pass it.
Part of the problem with the treaty (at least as it was originally suggested, I am unsure about now) was that it was not a balanced regulation across the board, instead giving certain countries more leeway under the treaty than others. To a degree I can understand this as more technologically savvy nations can focus more on cleaner emisions than third world nations, but a certain measure of fairness to all must be achieved before I would support it.
1) In regard to the IISS claim, you do know that reports are often made available to certain parties before they are presented publicly? I have no idea the circumstances of this issue so I will leave that as an honest suggestion for thought.
2) "Significant cause" != lying. Be honest with yourself.
3) These findings were actually backed up by a Congressional Committe and by the UK government, as well as other bodies. [here]
Overall, I would suggest that your characterization of lying, while not without merit, does not prove the "Bush led us into war with nothing but lies" argument that suggests we knew all along that there were no WMD, etc. etc. I realize that this isn't what I asked for, but I do wish that there were honest concessions on both sides of the fence and not this black and white "BUSH LIED!!!" / "KERRY LIED!!!" B.S.
What part was lied about before the war? Be very specific about this, links would help.:)
I think it's quite asinine that the administration won't come out and say it: "We're going in there to help stabilize the region in the long run and to preserve the weight of our growl in world affairs -- a decade of resolutions with no meat behind them will lead to more Iraqs in the future."
That said, I think it's also quite asinine to suggest that we knew Iraq didn't have WMD (if in fact they were not shipped to Syria, etc.) or that another decade of signing papers would fix the problem.
I would love for America to be more isolationist; the moment we're not worried about nukes in briefcases finding their way into Times Square or some nutjob with bad hair in some Aisian nation threatening us, I'll be on that bandwagon.
Hindsight seems 20/20. What would have happened if we had not fought the cold war with the (albeit unsavory) tactics we used throughout that conflict? We might be in a worse off place.
I am sure the majority of Americans, including the "right-wing nutjobs" would prefer to keep their families home and safe, but when you step onto our soil and slaughter 3,000 *civilians*, we are not going to stand back and be idle in world affairs. The Middle East is a big problem, and our backing of Israel and Kuwait has caused members of certain regimes to pull us further into this conflict, screaming and kicking.
The cold war had moments that could have been handled better. Every conflict has those, get over it. The cold war maybe should not have been fought, but that's a very risky calculation. The cold way maybe should not have been fought the way it was -- there's a good case to be made for that. Unfortunately, the "clean hands" argument makes those who use it seem very silly and naive. We've made some messes and we're reaping the consequences. So be it, now's time to deal with them.
So what do we do? Sit back and roll with the punches? Let every two-bit tyrant with a mouth and a red button bomb our cities or buildings or those of our allies? Should the Bin Ladens and Irans and North Koreas and Iraqs be let to say and do as they will? Isolationism on behalf of the US helped cause two world wars in the past and now that we've been struck hard it's not like we're going to sit back and do nothing.
So. Am I concerned about the way our allies see us? Very. Am I concerned that we're not behaving as well as we could be in the M.E.? Very. But is it asinine to suggest that the U.S. is just doing as it pleases because it pleases? Very.
Is it not also true that folks with higher level degrees tend to be put into more focused positions like research or management?
It's been my perception that higher level degree folks go to the big companies. The jobs there are more focused and the large companies can pay the large paychecks and give good benefits. To be honest, you can keep them.
I personally love the small company I work for. Great people, awesome environment, lots of room for career development where you can do what you want instead of micromanage an isolated project.
My impression is that higher level degree carrying folks are often passed over in small companies because of fears that they will leave for big-bucks jobs and that they may not be as flexible as someone with only a BS.
I know/. is pretty education biased, so let me pose this question to the managers out there who have been doing it for a while, preferably those in small-middle sized companies: what do you think about all of this?
Slashdot Mirror
"People don't like to be meddled with. We tell them what to do, what to think, don't run, don't walk. We're in their homes and in their heads and we haven't the right. We're meddlesome."
-- River Tam
Go ahead, turn some knobs. See how it affects the lives of complete strangers.
...forced DUI checkpoints and they DO draw blood if they want to...
In Texas, they have to get a court issued warrant to draw blood. It is considered, as I understand it, by our supreme court as a violent act - extracting part of your body against your will. Is it different in any other states? Can the officer on the scene make that determination? Links? Something else to rage about today... :
Maybe they should have tried Kleptomism instead of Kopimism? ;)
Let's remember that originally the point of the GPL was to allow people to share source freely, so that you could pass your work on and be assured that other users could pass it on too. It prevented restrictions on the sharing of something you created. It made your work open and free.
If I understand this right, and GPLv3 requires the allowance of "modifications in place", the GPLv3 is going far beyond that. It's no longer about keeping code open and free, it's forcing others to make their property open and free. It's no longer about sharing your work, it's about how your work is used.
Regardless of how you feel about "tivoization" -- personally I hate it -- this is telling someone else what to do with what they created. That's not making a statement about your own property, it's making a statement about somebody else's.
I'm a developer. Developers have the right and justification to release software under whatever license they choose! If a dev wants to restrict against "Tivoization", that's fine.
But let's not kid ourselves that "modifications in place" is about sharing software. This is going much further, and people with an interest in engineering things for the world to benefit from and making a living in the process have a very well qualified criticism.
http://www.qdb.us/305324
<Pomax> 20 years from now, someone is going to have the radical idea to give users access to the underlying OS, rather than to the browser API, and he will be heralded a revolutionary.
<Pomax> All manner of programming languages will pop up that work outside "the browser", giving access to "offline" applications, storing files in "user space", even perhaps running in something called "kernel mode".
<Pomax> It'll be a brave new world.
<Mirell> It's scary that's believable.
You're spot on. All it takes is one $0.02 sticky note with a Mult1pl3.R3str1c71Ons.En4rced password written on it to make all this huff and bluster worthless in most IT environments.
People seem to forget that Users use computers. Not Security Nuts. Not IT staff.
Real security accounts for social factors. The reason the Sup3r!Pa55w0rd policy fails is the same reason the easiest way into a network is often social engineering. Users. Security is not purely technological problem.
Security starts with taking your weakest link into account. Hint: It isn't that your "10 character minimum, 2 character subset" requirement is too weak.
Employees should backup their own data. If they are uncomfortable with the possibility of Employer wiping their personal phone, then they should not connect their personal phone to work email.
This is stupid.
There should absolutely, absolutely be a way to wipe a corporate account off a phone. That data is the property of the corporation.
But wiping everything is just inane. There is absolutely no reason to wipe pictures, personal contacts, emails, etc. This is software we're talking about. Just wipe the account(s) in question.
The only thinkable reason to wipe data outside of the corporate account is "you could have copied work content elsewhere," and that argument applies no more to phones than to personal computers. Hell, it applies to printed material too. Had any former employers snooping through your house lately?
No, the onus is on the corporation to restrict dissemination of corporate data if the risks are too high. Allowing a remote account wipe is a luxury afforded by software, not a corporate right over personal property.
A sincere thank you for the reply.
Respectfully, I believe you're going down a bad road. For a small application, and a developer who isn't asleep at the wheel, what you're suggesting can work OK; I imagine it hasn't been a problem for you.
Generally, for everything else, it tends to blow up down the road. And even for smaller projects, the benefits of keeping your logic out of the DB (faster, cleaner, clearer, easier to learn, easier to update) are significant.
I sincerely want to make an effort to be useful to folks who may not have worked with larger projects before. Please take this post in that spirit. It's a long, and I hope informative, post.
Make your code's intent clear ... alternatively, write logic in the right context
The biggest problem is code intent and flow control. Databases model data, GUIs model user actions, but neither necessarily model business logic. You've got business logic code for that -- like your permissions handling.
Code has a logic-centric view. Databases have a data-centric view. If you write logic in the DB, you're abstracting what you're writing from what you're actually trying to accomplish.
Error handling is a great example for flow control. Trapping an error in the DB, correctly identifying the problem and bubbling it up in a user-appropriate way in a clean fashion, as you said, is difficult.
Keep your code together
Another big problem is finding all the right code. For a newbie or a dev who hasn't looked at a bit of code in 6 months, this is very important.
Breaking your code up into different buckets based on what data it modifies makes your logic - your flow - hard to follow for anyone who isn't intimately familiar with the project.
Consider two implementations for a feature:
1) Application code triggers an update to three tables. A bunch of magic spread across several triggers on those three different tables and written in (depending on your implementation) three different schema files, or one huge file with your entire schema, updates three additional tables. E.G.: "most complex updates are performed using triggers and rules"
2) One function in one file that, in a transaction, updates six tables.
Which is easier to follow? From which implementation can you get a clear vision of the intent of the code? Which is easier to skim? If a new developer looks at your code, in which implementation is he more likely to miss something the feature touches?
Don't make interoperability harder
If you push logic into your DB, interoperability becomes harder, not easier. Before, you had just data, and two different applications could use it differently and have different requirements -- as long as what they did was consistent with the data model (your schema).
Now, with logic in the DB, anyone wanting to share your data has to work around your triggers, or co-opt them, or write entirely new triggers, procedures, and generally muck up your application to accomplish their goals.
Keep your platform flexible
Pushing logic into the DB, you may have made it easier to switch languages (although you still have a bunch of "front end" code you'd have to convert/maintain), but now it is much harder to switch databases. What was once merely data is now jumbled up with your application. If Oracle, MSSQL, etc. becomes a necessity, you're not just switching databases, you'll likely be refactoring significant chunks of your app.
Most business needs won't demand you switch languages (worst case, cross-compile or use IPC). Some business needs will demand you switch databases -- my company is now porting our app to MSSQL.
Your database is likely your bottleneck
In my experience, the first serious scalability problems most apps encounter are in the database. And the solution is always "more hardware." Beefier machines.
Then comes horizontal scaling ("moar serve
The problem wasn't that the databse was used in a wrong way.
While the database platform may have been a problem, the first, biggest problem wasn't the hardware. It was (bolded for effect): business logic does not belong in your DB, excepting a handful of cases.
I wouldn't normally have replied -- I agree with your point about hardware -- but this deserves to be underscored because so many people fundamentally do not get it.
I work for a company that was just bought out. Our new parent company develops a well known (in its industry) enterprise desktop application. The entirety of their business logic is written in the DB.
It's a maintenance nightmare, difficult to integrate with outside systems, and the system does not scale. Scalability is kicking their ass... because they can't.
Our company spends much less on hardware (and software, cheers for PostgreSQL), and our application is a billion times easier to develop and maintain. We use triggers - but only a handful.
People develop middle layers for a reason. Better code organization and flow control, much, much better speed, scalability, and flexibility.
Use a DB for what it's good at (ACID, data integrity).
save the time and other expenses of a database or key-value store lookup of a session id on every request.
So you save time on a cache/DB lookup by doing crypto processing instead ... after which your web application will begin processing the user's request... in most cases querying the database, updating user history, etc.
This seems to me like missing the forest for the trees.
Doing a hash lookup on your cached session is near constant time, avoids security holes introduced by sensitive data client-side, and avoids stacking session data on top of *every request* to the webserver.
That's not even tackling the more serious issue of trusting a user ID from the client without a password because "it's encrypted".
Heh. I live in Texas, one of the few "deregulated" electricity markets in the US.
Our local power lines are owned and maintained by regulated monopolies which set prices per area for monthly maintenance fees.
Power companies then contract with the local infrastructure owner to provide power to the grid. And as a homeowner, I choose which power company I give money to; I pay them for how much electricity I use from the grid, and they generate the electricity. I also pay the maintenance fee passed from the local owner through my power company.
When I chose a power company, I was able to look up JD Power reviews and pick the best company. I had a choice.
How many people can say that?
Clearly you're not using Perl the way it was meant to be used.
I think Larry might disagree with your assertion that Perl was meant to be used in a specific fashion.
It might be worth clarifying: Perl is great to learn, but terrible when you work on code written by people who don't think like you do.
Perl code can be simple, straightforward, very easy to pick up and hit the ground running. It's when you start coding with other programmers that it becomes painful.
The problem resolving this issue in the language design is that people will code they way they think, regardless of your restrictions. What happens when you put a C developer in a Java shop? Instead of writing beautiful, flowing OO code that glows with elegance, they'll write clunky, low-level functional code that steps through their thought process procedurally.
Ditto if you put a Java developer in the world of C. They'll prefer to write large data structures and significantly abstract their code, which will drive a lot of C developers nuts.
My point is, I think the result of requiring a programmer to jump through language hoops often means the resulting code is not only written in a different style, it's now obfuscated further because the programmer dodged your language hoops to do it.
--
I will say, however, that some Perl programmers happen to really love their esoteric, obfuscated language tricks, things like this. I definitely see what is being accomplished -- implicit but short code is often easier to skim and understand than long and explicit where you lose the meaning -- but I think Perl hackers tend to take this much too far.
Sarbanes-Oxley? Really?
You fight for this nonsense, thinking that it restricts big corporations. It does. ...just like everyone else. Including, and *especially*, newcomers.
Who does it really affect more? The company with a professional staffed legal team, entire departments dedicated to training, procedure, and lots of liquid assets to cope?
Or the little guy?
Spend some time thinking before you "shoot the buy guy to make things even." You're aiming at everyone.
The most important axiom in regards to this topic, as I've always said, is:
"Good defaults, lots of options."
Users need good defaults that allow them to get going quickly and that allow them to interoperate with other users and software. Users also need access to options that break compatibility but allow flexibility (such as nonstandard window managers and apps). The user turns on options as his/her own risk; this is how it should be. This is not an either-or situation, unfortunately most people don't recognize this.
Emphasizing this axiom when designing software will balance your software between normal users and people who like to customize their computing environments. You CAN keep both crowds happy; power users don't mind seeing a healthy set of options and newbies won't ever bother, they'll use the software regardless. Applying intelligent organization is the filling that makes this work.
That all said, there is a LOT to like about Linux, the free aspect -- as in both beer and speech -- being a huge part of that.
Still, as big of a Linux nut as I am, they have a long way to go before Linux becomes useful on the desktop without someone around to support it. The flipside of what I'm saying is that people with a geek in the family or companies with a competent IT department can use it wonderfully.
Cheers
I imagine they took out the whole "Hell" storyline because it's just cheesy and they need to sell it to the masses to make money.
That said, I would advocate doing something like Event Horizon - describe "Hell" just like it is, a dimension of chaos, blood, torture, mutilation, etc. etc. but never call it Hell. It's still creepy and can follow the generic Doom storyline, but sell-able IMO.
I can also understand why it's not just one marine and why Sarge (played by The Rock) is leading a team -- makes for more characters, character development, and, well, a movie instead of a video game.
But I do not understand for the life of me why the whole Mars City thing had to be abandoned. I honestly think that a slightly modified Doom 3 plot (don't call it Hell, maybe remove a certain scientist from the plot, Sarge leads a team of Marines) would work very well. Especially if they start it out the same, but perhaps draw the intro out a bit.
But what do I know? I'm sure it's too much to hope for that what I've heard is wrong.
What kind of company prevents a very competent employee from moving up in the ranks?
It's called career development, and managers with a clue and respect for their underlings take it upon themselves to HELP promote folks. This means giving raises, offering new opportunities, etc. After handling grunt work for a while, you're given control of a project with oversight. Then you're given control of a project with final approval resting with someone else. Then you get control of a project. Then you become official "management".
The process is gradual, thus negates the common "a degree means you stand a higher chance of being management capable."
I'm sorry, it's quite possible I just have my head up my arse this evening, but in anything but a huge company with lots of red tape, why on God's green earth would you not be able to move into management without a degree?
Cheers
"So wait, Kyoto doesn't go far enough. Therefore we shouldn't sign it. I mean, its a start, right?"
Ever have a day at work where your boss wants to do something half-assed and you know if your company goes that route, doing "just enough", you'll be stuck with the bill of fixing it in a year when it becomes insufficient?
I know this doesn't relate to a lot of the Slashdotters who don't have jobs but love to comment on the Real World.
America isn't about to legislate something that gives others an advantage in industry, especially with the half-assed solutions the "international community" puts through. Likely we'd get stuck with the bad end of the stick for a few decades until enough of the centrist population started rabbling about the environment again.
I'm all in favor of protecting the environment, it's one of the few things in this world I see as public property, but given the apathetic and self-interested nature of every civilized nation on this planet (especially the US, France, Germany, China, Russia, et. al.), if we're going to do this let's do it right across the board.
Period.
Arguing for something that forces companies to behave more like companies for their own sake has no merit. It is the freedom of the human beings who own and run those companies to make their own mistakes.
Now passing treaties and such to help the environment is another issue which I generally support, but you must make the distinction. The government isn't here to tell companies how to run themselves, and though this treaty in some cases may make companies more profitable long-term, that is at best a nice side-effect of the treaty but not a founding reason to pass it.
Cheers
Part of the problem with the treaty (at least as it was originally suggested, I am unsure about now) was that it was not a balanced regulation across the board, instead giving certain countries more leeway under the treaty than others. To a degree I can understand this as more technologically savvy nations can focus more on cleaner emisions than third world nations, but a certain measure of fairness to all must be achieved before I would support it.
Anyone care to add?
Cheers
1) In regard to the IISS claim, you do know that reports are often made available to certain parties before they are presented publicly? I have no idea the circumstances of this issue so I will leave that as an honest suggestion for thought.
2) "Significant cause" != lying. Be honest with yourself.
3) These findings were actually backed up by a Congressional Committe and by the UK government, as well as other bodies. [here]
Overall, I would suggest that your characterization of lying, while not without merit, does not prove the "Bush led us into war with nothing but lies" argument that suggests we knew all along that there were no WMD, etc. etc. I realize that this isn't what I asked for, but I do wish that there were honest concessions on both sides of the fence and not this black and white "BUSH LIED!!!" / "KERRY LIED!!!" B.S.
Cheers
What part was lied about before the war? Be very specific about this, links would help. :)
I think it's quite asinine that the administration won't come out and say it: "We're going in there to help stabilize the region in the long run and to preserve the weight of our growl in world affairs -- a decade of resolutions with no meat behind them will lead to more Iraqs in the future."
That said, I think it's also quite asinine to suggest that we knew Iraq didn't have WMD (if in fact they were not shipped to Syria, etc.) or that another decade of signing papers would fix the problem.
I would love for America to be more isolationist; the moment we're not worried about nukes in briefcases finding their way into Times Square or some nutjob with bad hair in some Aisian nation threatening us, I'll be on that bandwagon.
Cheers
Hindsight seems 20/20. What would have happened if we had not fought the cold war with the (albeit unsavory) tactics we used throughout that conflict? We might be in a worse off place.
I am sure the majority of Americans, including the "right-wing nutjobs" would prefer to keep their families home and safe, but when you step onto our soil and slaughter 3,000 *civilians*, we are not going to stand back and be idle in world affairs. The Middle East is a big problem, and our backing of Israel and Kuwait has caused members of certain regimes to pull us further into this conflict, screaming and kicking.
The cold war had moments that could have been handled better. Every conflict has those, get over it. The cold war maybe should not have been fought, but that's a very risky calculation. The cold way maybe should not have been fought the way it was -- there's a good case to be made for that. Unfortunately, the "clean hands" argument makes those who use it seem very silly and naive. We've made some messes and we're reaping the consequences. So be it, now's time to deal with them.
So what do we do? Sit back and roll with the punches? Let every two-bit tyrant with a mouth and a red button bomb our cities or buildings or those of our allies? Should the Bin Ladens and Irans and North Koreas and Iraqs be let to say and do as they will? Isolationism on behalf of the US helped cause two world wars in the past and now that we've been struck hard it's not like we're going to sit back and do nothing.
So. Am I concerned about the way our allies see us? Very. Am I concerned that we're not behaving as well as we could be in the M.E.? Very. But is it asinine to suggest that the U.S. is just doing as it pleases because it pleases? Very.
Cheers. Hope nobody takes this as a flame.
Part of the difference is that in books/TV/movies, you're watching it happen as a spectator. In a game, you're actually doing the shooting.
Not that I think this case has any merit, but there is a difference.
Cheers
Is it not also true that folks with higher level degrees tend to be put into more focused positions like research or management?
/. is pretty education biased, so let me pose this question to the managers out there who have been doing it for a while, preferably those in small-middle sized companies: what do you think about all of this?
It's been my perception that higher level degree folks go to the big companies. The jobs there are more focused and the large companies can pay the large paychecks and give good benefits. To be honest, you can keep them.
I personally love the small company I work for. Great people, awesome environment, lots of room for career development where you can do what you want instead of micromanage an isolated project.
My impression is that higher level degree carrying folks are often passed over in small companies because of fears that they will leave for big-bucks jobs and that they may not be as flexible as someone with only a BS.
I know
Cheers