Shell scripts have horrible error handling, and quickly become a maintenance nightmare. These days, e.g. Python is installed everywhere you need to go.
Python doesn't help much over shell scripts without extra libraries, which may or may not be present on any given system.
Python has changed incompatibly several times already.
Python has a large startup overhead:
20 seconds: 1000x python -c 'print("test")'
2 seconds: 1000x sh -c 'echo test'
Python is clumsy to use for gluing several programs together.
Python is not the same syntax as the shell. If you don't learn the shell then your day-to-day command lines are gimped.
So Ruby or Python or anything else is better for writing actual programs that do anything complicated, but there are plenty of appropriate uses for shell scripting. Ruby is actually much better... since it has a sensible syntax you could make a rubysh that wouldn't suck.
I just don't see what the harm in letting people who own pipes on the internet give preference to different traffic on those pipes.
The fundamental problem is that the people owning the pipes would charge for a service they would not be performing. The ISPs would charge extra to deliver timely to google, for instance, when they only pass the packets off to the next part of the network and not to google. The people owning the pipes to google are actually providing a service to google, and set the price accordingly.
I think even a libertarian would agree that companies charging for services they do not provide is not a legitimate function of a market.
It isn't about the menial hops between you and Google. It's about ISPs deciding who can and cannot have a meaningful presence online.
Actually net non-neutrality affects ALL hops that your packets take, it's just that the ISP is a choke point where they can demand bribe money from specific destinations, like google for instance, in order to connect to those users. It's a classic shakedown, because ISPs are already getting paid for the bandwidth used and there is nothing special about a given destination except how much money they have.
But it doesn't stop there. AT&T can say to Qwest that they'll need an extra cent per MB of traffic routed to google. Then instead of routing being a 'simple' issue of getting packets to the destination address, it adds weights like 'at minimal the cost' or 'cheapest in 0.X seconds' and so on.
'Net bias' is really a bone-headed idea in pretty much every way.
Re:lawyers are the same as computer programmers
on
You Are Not a Lawyer
·
· Score: 1
they both work in a complex technical language
The difference is that lawyers are still 'programming' in 'Prolog'. AFAICT the legal system works by the police saying here's a bunch of facts and then the prosecutor saying:
?- criminal(you) No
Then they add whatever random irrelevant facts like "on main street" or "in a horseless carriage" or "with the candlestick" until
used to like Opera, but they just strike me as a pack of whiny bitches complaining about how it is unfair that Microsoft is so successful. It should be disconcerting to the regulators in the EU that Firefox is also better off, Safari is probably there too and Chrome is also in a position to move past Opera in marketshare.
wget www.google.com | cat:
Web Images Maps News Gmail more
Google
[--------------] Advanced Search
Search I'm lucky
<blink>Have you tried Chrome? It's freakin awesome! It kicks the llama's ass and you must try it NOW!
Yeah, I'm sure Opera developers have no reason to complain that their competition is all either leveraging monopoly (MS, Apple) or near-monopoly status (Google) or giving (Mozilla) a million-man-hour product away for free. I myself don't care for the Opera browser, but even if they are whiny bitches they've certainly earned the right to be.
It's not just nationalism. It's hubris. That has been a part of Russia's collective psyche for at least the past 100 years. They're not going to let anyone tell them what to do, and they balk at receiving help from anyone - it's a sign of weakness.
Russians are Klingons. They are belligerent and drunk all the time, use brute force whenever possible, would rather die that surrender. Yet somehow they are a spacefaring society that always ends up saving the day with their cargo ships and scrapped together heaps. It defies logic.
Yet, we have enough people that have posted to the CFL discussions with evidence that even with this, you're releasing less mercury into the environment overall.
So what's better:
1) Use incandescents and mercury in the air is X ppm 2) Use CFL and mercury in the air overall is X/2 ppm, but in your house is 16X ppm?
The rational choice is #1, use incandescents even though they are worse overall for the environment.
CFL is simply not a good source of lighting, it's just that they cost somewhat less than incandescents and to many people cost (including labor to replace bulbs) is more important than the negatives. Aside from cost, to individual people CFL are worse in every respect... incandescents have better color temperature, are instant on, are less prone to fires*, are dimmable, don't humm or hiss, and don't interfere with electronics.
* - don't forget that CFLs have complicated electronic ballasts and other electrical components, which can fail spectacularly and catch fire. When you talk about environmental hazards, also include fire-proofing chemicals in the plastic bases. Although granted halogen torch lights have probably caused more fires than CFLs ever will...
Your bug was a serious issue (locking up the interface for 30+ seconds), was marked 'cant reproduce' even though lots of other people said they had the same problem. In the end, months later, the problem still exists.
A user finally found a work-around. That's great, but hardly inspirational... if the user posts that his clock text looks bad then months later maybe, if he's lucky, there might be something he can do to work around the problem. And then everybody else with the same problem has to find that bug report or they're screwed, and everybody individually has to work around the problem themselves.
Every bug report I have ever submitted to a substantial open source project (including GNOME, Ubuntu, GIMP) has been addressed in a relatively timely manner.
I guess by 'addressed' you mean either 'closed; can't reproduce'? or 'closed; wont fix'
Not only is rude to assume that the developers are so incompetent that they will by default just leave the bug in purgatory forever, it's also not what I have experienced with most open source projects. Every bug report I have ever submitted to a substantial open source project (including GNOME, Ubuntu, GIMP) has been addressed in a relatively timely manner.
And have you submitted bugs that cannot be reproduced? Because this is what the OP was talking about.
I've submitted bugs that can't be reproduced, some well-known such as static in the left audio channel (since at least 2.6.21, still not fixed despite lots of people with same problem), and several others. The only bugs that have ever been fixed were ones that were easily reproducible. IF they are reproducible THEN you get a hit-or-miss where there's either developer that sees it right away and fixes it or it sometimes gets 'lost' for a while. One of the bugs I submitted for firefox finally got fixed after >1 year.
I think some of you guys, including the moderator who spent his points for a cause rather than merit, mistook my post as some kind of slight against KDE or open source in general. It wasn't meant that way, only that having outrage against somebody for not filing a non-reproducible bug is way over the top.
Powers of N are convenient for humans. Other societies have counted in base 20 (mayan,irish), 60 (sumerian), etc. People can even count in number systems with more than one base (5 and 20 for instance).. In contrast, binary computers are always going to use base 2 since it would be absurd not to.
So you have one side that's flexible and one that is not. The 'proper' solution then isn't to create two different units of measure, but for people to use a different base. Octal for instance... make thumb and big toe not count as fingers and you're all set (they could be use to mark powers instead).
Or wait, you weren't actually interested in solving the problem were you?
There shouldn't be bug report for this category of obvious flaws. If you had one look on the desktop you would have seen it.
Fallacy. If we had one look at the OP's desktop then we would have seen it. Unfortunately, the users who test KDE cannot possibly test every permutation of hardware that exists that supports KDE. It's simply impossible. However, I'm willing to bet that the machines they did test on did not exhibit this problem. Hence, they never knew a problem existed.
So... the bug report will be marked "Cannot reproduce". Then a couple other suckers that were so annoyed by it that they took the time to create an account in the bug system will post "Still reproducible on 4.4", but it'll never get fixed. And even if it does get fixed, the bug report will never be changed from "Cannot reproduce" to "Fixed" since it's lost in the morass. The people who filed and posted 'me too' and the people that read the report and didn't register will all be even more pissed off.
Testing and bug tracking does not work well when the underlying code is really buggy. Quality of a program should be judged by its worst part... it's better to have good quality throughout than to have some perfect code mixed in with some really bad code. IOW, there shouldn't be problems with just a couple fields being a couple pixels off like that.
dedicated ray tracing hardware has been around for decades as standalone hardware
Your example has 14 dual-core processors at less than 200 Mhz, which if it is based on its predecessors is a traditional RISC chip, meaning lots of pipeline stalls. You also had to use their rendering software. It has all the memory access problems I mentioned. This is NOT AT ALL SIMILAR to what I was saying. You completely misunderstood my post if you think this hardware has any bearing.
Image a system with 10,000 100 Mhz cores on a single CPU. Now compare rasterization vs raytracing on that machine. The MTA docs seem to be hard to find nowadays... look at Sun's Niagara for a watered down version of this.
4. Scene complexity is inherently limited by 1 other major factor that you've completely ignored. Memory speed. As your data set increases, rendering performance degrades to the speed at which you can feed the processors - i.e. the speed of the memory. Again, this is another reason why we seperate the scene into render layers.
What's neat about raytracing is that the memory access can be divided into millions of separate 'threads' that are not dependent on each other. So, with a processor (such as Tera MTA) where threads run in the order that memory is available you achieve maximum memory bandwidth.
On 'modern' processors where memory is read in the order that threads run you get massive pipeline and cache stalls when using a software raystracer. So when you are comparing the 'vs' of rasterization and raytracing you need to consider that raytracing currently has thousands of hands tied behind its back.
Raytracing never really made the in-roads into the FilmFX world that the early 80's/90's evangelists predicted - And i predict that it will never make the in-roads into Games that you seem to believe.
I think it's exactly the opposite. 'FilmFX' world isn't using raytracing because it hasn't been used in games. Games drive this tech, and if we get fast hardware for raytracing then movies will use it exclusively.
It's really been a hardware issue... designing an asynchronous CPU with millions of thread AND getting it to interface efficiently with a PC card bus is basically impossible. But, move the renderer into the CPU itself and it's far, far easier and faster on all fronts. For that reason I see raytracing soon getting it's first real chance to compete head-to-head.
Equally well, you can't say that putting socks on can't destroy the planet, yet I would assume you're willing to take that risk...
Again, really bad reasoning. Something reasonably analogous is "wearing the same socks two days in a row can't get your fired from your job" (something seemingly innocuous causing something 'catastrophic'). Your feet might be smelly, but nobody could *possibly* get fired because of it. Well, I'm not so sure that's always true -- but maybe you are.
And don't get me started on people who say "it's just as likely that...", which you just did with 'equally well'. Nothing in the real world is the same probability. You're equating the possibility of a sock causing worldwide destruction with a BLACK HOLE and you see no difference between the two. They may in fact both not cause such catastrophe, but to claim some kind of equivalence between them is absurd.
What I object to is exactly that kind of reasoning.
I'm not a particle physicist, so I don't know the math and formulas and such, but what I do know for sure is that they are incomplete. Our physics doesn't completely account for everything in the universe so there is no way you can say that just because high energy particles have been hitting the planet for eons that LHC can't destroy the planet. For instance, when was the last time a high energy particle hit the earth near a torus of high energy particles and huge magnetic fields? Oh, that hasn't ever happened in the history of the planet you say? Interesting.
These physicists are people, like everybody else, and they make the same kinds of mistakes. I can't count the number of times debugging a program crash that I've said or others have said that the cause can't possibly be X because we know for a 'fact' that the code is correct, only to have it turn out to be exactly that. That's the same scenario, only seen from the opposite direction. People make bad decisions and especially when they are invested in that decision (like, it being the culmination of 40+ years of your work...).
The Japanese started using kamikaze tactics in WWII when the leadership already knew or should have known that the war was a lost cause. It was a futile and cowardly act by their leaders which in the end changed nothing.
Kamikaze tactics in WWII achieved nothing only because we invented the proximity fuse so they could be shot down before reaching the ship. If not for those fuses we would have lost most or all of our ships or given up.
You can't take 100:1 losses. You need to change the game so that you don't take those losses. Suicide bombing will work regardless of whether you, Joe Spectator, thinks the side using it is 'stupid' until we have some way to neutralize that tactic.
It's like saying you couldn't 'get into' LoTR because you got to the story of Tom Bombadil and you saw there was 'no plot arc'. Or that the Hobbit was just 'a collection of random stories strung together'. Just because not every event furthers a plot doesn't mean there is no plot. BSG is not that quality, but it's disingenuous to compare it to Lost.
Mostly what I've heard from people that didn't 'get into' it are things like 'they use wired phones?'. There are a lot of things like that in BSG where they demand you suspend disbelief. Some people can't grok that they could have space ships and can teleport through space and invent robots that can think, but still use wired phones.
Again, the bad actor here is Kelly (see my other post). She got input from only one of the two people involved and then made her decision. What Kelly should have done is asked Stuart if he could make a better case for why he should manage a new combined division. She could have still pulled the trigger right then and fired him if he couldn't make the case.
What you guys are missing is that Kelly is the one that should have been fired. She chose to keep the guy who in a month will be trying to get her job, and fired the guy that had underlings who followed him out the door even in a bad economy (ie actually liked coming to work). On top of that, her decision was based on emotions ('too nice') instead of results.
That's pretty much a terrible decision any way you look at it.
Well, if as you say it's legal in your jurisdiction, then it sounds like yes, she should pay, unless she wants to risk damage to her credit.
I expect a 4-digit to be more precise... she may end up required to pay, but in no way should she pay!
IANAL, but in America this sort of scam is probably unenforceable because under common law a contract is only valid if both sides get 'just' compensation (meaning you aren't getting totally ripped off). For instance, you can sign a contract to landscape somebody's lawn for free, but by common law that contract is not valid. In this case, she would go to small claims court and the judge would weigh reasonable cost for their bandwidth and overhead against the cost of the personal information she gave them and if anything declare they owed her something.
Re:Large uptick in Qt usage?
on
Qt Becomes LGPL
·
· Score: 1
The only complaint I've seen before about Qt is that it's too expensive for proprietary apps
Here's a problem with Qt... it's C++. They sat down and said "lets build the very best C++ widget API", and they did. That's great, but lets think about this for a second:
* C++ is a terrible language to use for applications. Lack of garbage collection, incoherent error messages, poor error handling and recovery, no closures, etc. You know the drill.
* C++ is a terrible language for interoperability. 'Name munging', difficulty calling overloaded methods from C or other languages, compiler differences, etc. And Qt adds a few more problems like MOC and macros.
GTK is written in C which is an even worse application language, but far better for interoperability. Any language implementation can trivially easily bind to GTK functions. So I grant that Qt is an excellent C++ UI toolkit, but that's like saying a platypus is an excellent duck; the comparison has some merit, but mostly just leaves people scratching their heads.
"1 April 1990: A Standard for the Transmission of IP Datagrams on Avian Carriers"
The window size can be really small, like 3" on a side. Only dock your ship at well-known ports.
Also only use ports starting with 1024 since 1-1023 are underground; you need roots to transmit through these ports. DO NOT use portholes 1-1023 unless your avian carriers happen to be penguins.
What's broken is people thinking each step has to be 100% complete and 100% detailed. For instance later in your post when you say you end up with "maybe we've got 50% of the reqs done, maybe not". There is no 100%.
Waterfall is great when loosely adhered to:
* Requirements: get everybody on the same page to start with... what is this thing? * Design: how are we going to do it... what languages, client/server, mysql vs sqllite, etc. * Implementation: make it so * Testing: make sure it works
I don't see how there can be any other way; even a prototype has to generally follow those steps in order. How can you design something if you don't have the foggiest what it will do? How can you implement parts without knowing how they will fit together? How can you test something that hasn't been written yet?
The real problem with waterfall is at each step the people feel like the people doing the next step (or 'grading' their step) are idiots. So they try to be 100% complete and spell everything out in 100% excruciating detail. It's like testing, which ironically is only worth doing if the program is written well and has few bugs. If you don't trust that the next step is competent then you all fail.
That'll be interesting, then. By and large, every performance measuring I've ever seen has been flawed, and unless it was for very simple jobs, greatly so.
For programmers it's really easy. Just find the programmer that people go to when there's a problem they can't figure out and ask him who should be fired and why. These people know exactly who isn't pulling their weight and can explain why in detail.
If you need to fire more people, find the person who fixes everybody else's broken code and ask them.
This has the double benefit of firing the worst performers and reducing the workload on the better ones.
Slashdot Mirror
Shell scripts have horrible error handling, and quickly become a maintenance nightmare. These days, e.g. Python is installed everywhere you need to go.
Python doesn't help much over shell scripts without extra libraries, which may or may not be present on any given system.
Python has changed incompatibly several times already.
Python has a large startup overhead:
20 seconds: 1000x python -c 'print("test")'
2 seconds: 1000x sh -c 'echo test'
Python is clumsy to use for gluing several programs together.
Python is not the same syntax as the shell. If you don't learn the shell then your day-to-day command lines are gimped.
So Ruby or Python or anything else is better for writing actual programs that do anything complicated, but there are plenty of appropriate uses for shell scripting. Ruby is actually much better... since it has a sensible syntax you could make a rubysh that wouldn't suck.
I just don't see what the harm in letting people who own pipes on the internet give preference to different traffic on those pipes.
The fundamental problem is that the people owning the pipes would charge for a service they would not be performing. The ISPs would charge extra to deliver timely to google, for instance, when they only pass the packets off to the next part of the network and not to google. The people owning the pipes to google are actually providing a service to google, and set the price accordingly.
I think even a libertarian would agree that companies charging for services they do not provide is not a legitimate function of a market.
It isn't about the menial hops between you and Google. It's about ISPs deciding who can and cannot have a meaningful presence online.
Actually net non-neutrality affects ALL hops that your packets take, it's just that the ISP is a choke point where they can demand bribe money from specific destinations, like google for instance, in order to connect to those users. It's a classic shakedown, because ISPs are already getting paid for the bandwidth used and there is nothing special about a given destination except how much money they have.
But it doesn't stop there. AT&T can say to Qwest that they'll need an extra cent per MB of traffic routed to google. Then instead of routing being a 'simple' issue of getting packets to the destination address, it adds weights like 'at minimal the cost' or 'cheapest in 0.X seconds' and so on.
'Net bias' is really a bone-headed idea in pretty much every way.
they both work in a complex technical language
The difference is that lawyers are still 'programming' in 'Prolog'. AFAICT the legal system works by the police saying here's a bunch of facts and then the prosecutor saying:
Then they add whatever random irrelevant facts like "on main street" or "in a horseless carriage" or "with the candlestick" until
Seriously. Get a real language, lawyers.
used to like Opera, but they just strike me as a pack of whiny bitches complaining about how it is unfair that Microsoft is so successful. It should be disconcerting to the regulators in the EU that Firefox is also better off, Safari is probably there too and Chrome is also in a position to move past Opera in marketshare.
wget www.google.com | cat:
Yeah, I'm sure Opera developers have no reason to complain that their competition is all either leveraging monopoly (MS, Apple) or near-monopoly status (Google) or giving (Mozilla) a million-man-hour product away for free. I myself don't care for the Opera browser, but even if they are whiny bitches they've certainly earned the right to be.
Learn x86, C, Java, JavaScript. EOL.
Anything more is bonus.
Anything less is lacking.
It's not just nationalism. It's hubris. That has been a part of Russia's collective psyche for at least the past 100 years. They're not going to let anyone tell them what to do, and they balk at receiving help from anyone - it's a sign of weakness.
Russians are Klingons. They are belligerent and drunk all the time, use brute force whenever possible, would rather die that surrender. Yet somehow they are a spacefaring society that always ends up saving the day with their cargo ships and scrapped together heaps. It defies logic.
Yet, we have enough people that have posted to the CFL discussions with evidence that even with this, you're releasing less mercury into the environment overall.
So what's better:
1) Use incandescents and mercury in the air is X ppm
2) Use CFL and mercury in the air overall is X/2 ppm, but in your house is 16X ppm?
The rational choice is #1, use incandescents even though they are worse overall for the environment.
CFL is simply not a good source of lighting, it's just that they cost somewhat less than incandescents and to many people cost (including labor to replace bulbs) is more important than the negatives. Aside from cost, to individual people CFL are worse in every respect... incandescents have better color temperature, are instant on, are less prone to fires*, are dimmable, don't humm or hiss, and don't interfere with electronics.
* - don't forget that CFLs have complicated electronic ballasts and other electrical components, which can fail spectacularly and catch fire. When you talk about environmental hazards, also include fire-proofing chemicals in the plastic bases. Although granted halogen torch lights have probably caused more fires than CFLs ever will...
Your bug was a serious issue (locking up the interface for 30+ seconds), was marked 'cant reproduce' even though lots of other people said they had the same problem. In the end, months later, the problem still exists.
A user finally found a work-around. That's great, but hardly inspirational... if the user posts that his clock text looks bad then months later maybe, if he's lucky, there might be something he can do to work around the problem. And then everybody else with the same problem has to find that bug report or they're screwed, and everybody individually has to work around the problem themselves.
Every bug report I have ever submitted to a substantial open source project (including GNOME, Ubuntu, GIMP) has been addressed in a relatively timely manner.
I guess by 'addressed' you mean either 'closed; can't reproduce'? or 'closed; wont fix'
Not only is rude to assume that the developers are so incompetent that they will by default just leave the bug in purgatory forever, it's also not what I have experienced with most open source projects. Every bug report I have ever submitted to a substantial open source project (including GNOME, Ubuntu, GIMP) has been addressed in a relatively timely manner.
And have you submitted bugs that cannot be reproduced? Because this is what the OP was talking about.
I've submitted bugs that can't be reproduced, some well-known such as static in the left audio channel (since at least 2.6.21, still not fixed despite lots of people with same problem), and several others. The only bugs that have ever been fixed were ones that were easily reproducible. IF they are reproducible THEN you get a hit-or-miss where there's either developer that sees it right away and fixes it or it sometimes gets 'lost' for a while. One of the bugs I submitted for firefox finally got fixed after >1 year.
I think some of you guys, including the moderator who spent his points for a cause rather than merit, mistook my post as some kind of slight against KDE or open source in general. It wasn't meant that way, only that having outrage against somebody for not filing a non-reproducible bug is way over the top.
Let me explain this in simple terms:
Powers are two are convenient for machines.
Powers of ten are convenient for humans.
Powers of N are convenient for humans. Other societies have counted in base 20 (mayan,irish), 60 (sumerian), etc. People can even count in number systems with more than one base (5 and 20 for instance).. In contrast, binary computers are always going to use base 2 since it would be absurd not to.
So you have one side that's flexible and one that is not. The 'proper' solution then isn't to create two different units of measure, but for people to use a different base. Octal for instance... make thumb and big toe not count as fingers and you're all set (they could be use to mark powers instead).
Or wait, you weren't actually interested in solving the problem were you?
There shouldn't be bug report for this category of obvious flaws. If you had one look on the desktop you would have seen it.
Fallacy. If we had one look at the OP's desktop then we would have seen it. Unfortunately, the users who test KDE cannot possibly test every permutation of hardware that exists that supports KDE. It's simply impossible. However, I'm willing to bet that the machines they did test on did not exhibit this problem. Hence, they never knew a problem existed.
So... the bug report will be marked "Cannot reproduce". Then a couple other suckers that were so annoyed by it that they took the time to create an account in the bug system will post "Still reproducible on 4.4", but it'll never get fixed. And even if it does get fixed, the bug report will never be changed from "Cannot reproduce" to "Fixed" since it's lost in the morass. The people who filed and posted 'me too' and the people that read the report and didn't register will all be even more pissed off.
Testing and bug tracking does not work well when the underlying code is really buggy. Quality of a program should be judged by its worst part... it's better to have good quality throughout than to have some perfect code mixed in with some really bad code. IOW, there shouldn't be problems with just a couple fields being a couple pixels off like that.
dedicated ray tracing hardware has been around for decades as standalone hardware
Your example has 14 dual-core processors at less than 200 Mhz, which if it is based on its predecessors is a traditional RISC chip, meaning lots of pipeline stalls. You also had to use their rendering software. It has all the memory access problems I mentioned. This is NOT AT ALL SIMILAR to what I was saying. You completely misunderstood my post if you think this hardware has any bearing.
Image a system with 10,000 100 Mhz cores on a single CPU. Now compare rasterization vs raytracing on that machine. The MTA docs seem to be hard to find nowadays... look at Sun's Niagara for a watered down version of this.
4. Scene complexity is inherently limited by 1 other major factor that you've completely ignored. Memory speed. As your data set increases, rendering performance degrades to the speed at which you can feed the processors - i.e. the speed of the memory. Again, this is another reason why we seperate the scene into render layers.
What's neat about raytracing is that the memory access can be divided into millions of separate 'threads' that are not dependent on each other. So, with a processor (such as Tera MTA) where threads run in the order that memory is available you achieve maximum memory bandwidth.
On 'modern' processors where memory is read in the order that threads run you get massive pipeline and cache stalls when using a software raystracer. So when you are comparing the 'vs' of rasterization and raytracing you need to consider that raytracing currently has thousands of hands tied behind its back.
Raytracing never really made the in-roads into the FilmFX world that the early 80's/90's evangelists predicted - And i predict that it will never make the in-roads into Games that you seem to believe.
I think it's exactly the opposite. 'FilmFX' world isn't using raytracing because it hasn't been used in games. Games drive this tech, and if we get fast hardware for raytracing then movies will use it exclusively.
It's really been a hardware issue... designing an asynchronous CPU with millions of thread AND getting it to interface efficiently with a PC card bus is basically impossible. But, move the renderer into the CPU itself and it's far, far easier and faster on all fronts. For that reason I see raytracing soon getting it's first real chance to compete head-to-head.
Equally well, you can't say that putting socks on can't destroy the planet, yet I would assume you're willing to take that risk...
Again, really bad reasoning. Something reasonably analogous is "wearing the same socks two days in a row can't get your fired from your job" (something seemingly innocuous causing something 'catastrophic'). Your feet might be smelly, but nobody could *possibly* get fired because of it. Well, I'm not so sure that's always true -- but maybe you are.
And don't get me started on people who say "it's just as likely that...", which you just did with 'equally well'. Nothing in the real world is the same probability. You're equating the possibility of a sock causing worldwide destruction with a BLACK HOLE and you see no difference between the two. They may in fact both not cause such catastrophe, but to claim some kind of equivalence between them is absurd.
What I object to is exactly that kind of reasoning.
I'm not a particle physicist, so I don't know the math and formulas and such, but what I do know for sure is that they are incomplete. Our physics doesn't completely account for everything in the universe so there is no way you can say that just because high energy particles have been hitting the planet for eons that LHC can't destroy the planet. For instance, when was the last time a high energy particle hit the earth near a torus of high energy particles and huge magnetic fields? Oh, that hasn't ever happened in the history of the planet you say? Interesting.
These physicists are people, like everybody else, and they make the same kinds of mistakes. I can't count the number of times debugging a program crash that I've said or others have said that the cause can't possibly be X because we know for a 'fact' that the code is correct, only to have it turn out to be exactly that. That's the same scenario, only seen from the opposite direction. People make bad decisions and especially when they are invested in that decision (like, it being the culmination of 40+ years of your work...).
The Japanese started using kamikaze tactics in WWII when the leadership already knew or should have known that the war was a lost cause. It was a futile and cowardly act by their leaders which in the end changed nothing.
Kamikaze tactics in WWII achieved nothing only because we invented the proximity fuse so they could be shot down before reaching the ship. If not for those fuses we would have lost most or all of our ships or given up.
You can't take 100:1 losses. You need to change the game so that you don't take those losses. Suicide bombing will work regardless of whether you, Joe Spectator, thinks the side using it is 'stupid' until we have some way to neutralize that tactic.
It's like saying you couldn't 'get into' LoTR because you got to the story of Tom Bombadil and you saw there was 'no plot arc'. Or that the Hobbit was just 'a collection of random stories strung together'. Just because not every event furthers a plot doesn't mean there is no plot. BSG is not that quality, but it's disingenuous to compare it to Lost.
Mostly what I've heard from people that didn't 'get into' it are things like 'they use wired phones?'. There are a lot of things like that in BSG where they demand you suspend disbelief. Some people can't grok that they could have space ships and can teleport through space and invent robots that can think, but still use wired phones.
Again, the bad actor here is Kelly (see my other post). She got input from only one of the two people involved and then made her decision. What Kelly should have done is asked Stuart if he could make a better case for why he should manage a new combined division. She could have still pulled the trigger right then and fired him if he couldn't make the case.
What you guys are missing is that Kelly is the one that should have been fired. She chose to keep the guy who in a month will be trying to get her job, and fired the guy that had underlings who followed him out the door even in a bad economy (ie actually liked coming to work). On top of that, her decision was based on emotions ('too nice') instead of results.
That's pretty much a terrible decision any way you look at it.
Well, if as you say it's legal in your jurisdiction, then it sounds like yes, she should pay, unless she wants to risk damage to her credit.
I expect a 4-digit to be more precise... she may end up required to pay, but in no way should she pay!
IANAL, but in America this sort of scam is probably unenforceable because under common law a contract is only valid if both sides get 'just' compensation (meaning you aren't getting totally ripped off). For instance, you can sign a contract to landscape somebody's lawn for free, but by common law that contract is not valid. In this case, she would go to small claims court and the judge would weigh reasonable cost for their bandwidth and overhead against the cost of the personal information she gave them and if anything declare they owed her something.
The only complaint I've seen before about Qt is that it's too expensive for proprietary apps
Here's a problem with Qt... it's C++. They sat down and said "lets build the very best C++ widget API", and they did. That's great, but lets think about this for a second:
* C++ is a terrible language to use for applications. Lack of garbage collection, incoherent error messages, poor error handling and recovery, no closures, etc. You know the drill.
* C++ is a terrible language for interoperability. 'Name munging', difficulty calling overloaded methods from C or other languages, compiler differences, etc. And Qt adds a few more problems like MOC and macros.
GTK is written in C which is an even worse application language, but far better for interoperability. Any language implementation can trivially easily bind to GTK functions. So I grant that Qt is an excellent C++ UI toolkit, but that's like saying a platypus is an excellent duck; the comparison has some merit, but mostly just leaves people scratching their heads.
"1 April 1990: A Standard for the Transmission of IP Datagrams on Avian Carriers"
The window size can be really small, like 3" on a side. Only dock your ship at well-known ports.
Also only use ports starting with 1024 since 1-1023 are underground; you need roots to transmit through these ports. DO NOT use portholes 1-1023 unless your avian carriers happen to be penguins.
The waterfall is broken, seriously. ...
What's broken is people thinking each step has to be 100% complete and 100% detailed. For instance later in your post when you say you end up with "maybe we've got 50% of the reqs done, maybe not". There is no 100%.
Waterfall is great when loosely adhered to:
* Requirements: get everybody on the same page to start with... what is this thing?
* Design: how are we going to do it... what languages, client/server, mysql vs sqllite, etc.
* Implementation: make it so
* Testing: make sure it works
I don't see how there can be any other way; even a prototype has to generally follow those steps in order. How can you design something if you don't have the foggiest what it will do? How can you implement parts without knowing how they will fit together? How can you test something that hasn't been written yet?
The real problem with waterfall is at each step the people feel like the people doing the next step (or 'grading' their step) are idiots. So they try to be 100% complete and spell everything out in 100% excruciating detail. It's like testing, which ironically is only worth doing if the program is written well and has few bugs. If you don't trust that the next step is competent then you all fail.
That'll be interesting, then. By and large, every performance measuring I've ever seen has been flawed, and unless it was for very simple jobs, greatly so.
For programmers it's really easy. Just find the programmer that people go to when there's a problem they can't figure out and ask him who should be fired and why. These people know exactly who isn't pulling their weight and can explain why in detail.
If you need to fire more people, find the person who fixes everybody else's broken code and ask them.
This has the double benefit of firing the worst performers and reducing the workload on the better ones.