I think it is fairly easy for a person who has sufficient relevant skills to differentiate between disassembled binary that was written by hand and a binary that was generated using less-intelligent machine like a compiler. This is the whole point of being able to "verify the claim". We humans can do that. Then again, if they used macros to generate their binaries, despite it being called "written in assembly", repetitive chunks of instructions are bound to pop-up, confusing humans even more. It is not like what I described is an easy job. But is a fairly doable, and for an expert - consider folks who reverse-engineer viruses and worms, etc. - it is even a profession. So yes, verifiable claim. If you see obviously stupid instruction sequences, which looked completely unoptimized, unless written by a kid who just started with assembly languages, you know probably a compiler has written that, and not a particularly intelligent one either. Also, the more disassembled code you have to look at, if we ignore the size of it as time-factor, the easier it is to give a definite conclusion on whether the code was written by hand by a human or generated by software where human was only supervising (= compiler usage scenario).
Taking into account what happens on Wikipedia sometimes - vandalism - I gotta say it occured to me that the percent of vandals re-writing and thus spoiling good articles goes down in proportion to the size of the public for the amount of pages said Wiki would contain. Simpler put, Wikipedia being a Wiki for the broadest possible public - the general public, no restrictions - is substantially more suspectible to vandalism than say a Wiki shared, written and accessed by 10 individuals (an intranet Wiki, for example). Add to that a relatively simple fact that probably any soldier with his sanity in behold will refrain from mal-editing Wiki entries on semi-automatic rifles because he knows he may be shot in the head by one held by his comrade - this makes the Army somewhat more of a unity than the general public, which generally does not care much for one another - everyone being anonymous and all. In the army, they would think twice before resorting to Wiki vandalism, because they know they may have to fight side by side, in which case you need all experience you can get from your buddies. The two factors should make for a very useful implementation indeed.
This what you get with 7 billion people on the planet. Over-worked worker bees. We all drink Gatorade, now time to give some to bees. No slacking off on this crowded rock!
I hate to repeat myself, but here goes: don't give me that crap. And here is bonus line, since space is obviously so cheap here: gods forbid I ever attempt to write something like KDE in KDEs spirit.
Thanks for correction. I never used Bootcamp, but I did assume (and obviously it does) it presents some sort of incompatibility for Windows running on a Mac. Probably it is Windows not having a good driver to interface Mac internals.
Hate to disagree with an expert but I have seen several cases where badly designed code directly affected battery. I am on Linux, and have got a habit of peeking into its source code, after checking with Intels "powertop" utility. Recently, I found out for example that ffmpeg uses a 1000hz timer to play a HTTP-delivered MP3 stream with bitrate of 56Kbps. Stuff like that. Of course not always it is due to bad code, but often it actually is.
Also, I do application software developing for a living, and in my case there has been minimal occurences where said manager actually came back and revised the software to include better powermanagement. Granted, they do exactly as you described - "let us first make it work". But after it is shipped, nobody cares for the code. Of course, many may say that I have been employed by really shitty managers/employers, and it would partially be true.
So, it is NOT JUST management. It is a multitude of factors, involving management AND coders. Both affect each other as well.
Faster and cheaper is the curse of our times. I hate that shit:-) I acknowledge its necessity in practical living, but it should be a temporary step on the way to "faster, cheaper, better" but it usually stops after the first two qualities are achieved.
The problem is not specific to Windows or MacBooks. Many developers code as if the only machines that will run their software are permanently el-grid-connected servers or workstations. Polling loops with insane timers (like 1000hz), and they also take the advice "don't optimize prematurely" to mean "don't optimize unless you are payed for it". Re-drawing the display even if it is not needed at all, copying data structures all over, etc. No wonder batteries drain.
In this case I believe all three are to blame - neither alone is the culprit - I mean Windows usually is compatible with real hardware enough to last couple-three hours on an average laptop battery doing average desktop stuff, MacBook is about the same. Probably BootCamp taking battery awareness too lightheartedly and/or unable to optimize for specific cases like virtualized Windows code running.
Funny how it takes nothing short of an uproar to convince those marketing bozos to back down. Somehow, their morale is so crippled they cannot see on their own what is good and what is not. Time after time they try, trick after trick, to move the goal line as it benefits them. Darwin was right indeed - the environment you have to survive in (marketing dept. in this case) determines the kind of creature you are. When two groups are so segregated, that one sneaks in commercials in hope the trick will pass uncovered, and the other nervously ready to uproar at the slightest suspicion, this industry is so definitely not what it once was. There is war going on - customer vs. vendor. And that is okay, nothing new here. What is hilarious, how all vendors talk like they appreciate their customers, how the customer is always right and what not. Well, apparently it takes a very angry customer to convince them he is right. Everything else is considered an ambiguous signal, the machine does not interrupt the process.
I was blindly assuming I am posting in plain text, since I had personally set it up so in user preferences long ago. Which it now wasn't, probably because I flushed my cookies not long ago, even though I don't know if the actual preference is bound to the user profile or a separate cookie indeed. Was it so hard to understand what I was "rambling" about? You actually come across as more intelligent than many people here, who like to push sarcasm in front of their lack of relevant argument, which they do not even bother talking about, instead using Slashdot as a convenient place to spit out their unprocessed hate.
This is not a web-design forum. I was typing WITH paragraphs, if you have objections, direct them at whoever is responsible for resetting my "Post as" preference to "HTML formatted text" and whoever forbid editing posts. After that, you may look at the head of the page, it should bring you back to what the discussion is about.
If your attention span limits you to only comprehend three sentence posts with no lasting meaning, I guess you are part of the target KDE audience.
Forgot to mention that obligatory remark here: KDE is 4 million lines of source code; Windows these days is about 50 million (Windows Vista, acc. to Wikipedia); KDE 4.3, a subsequent version of a desktop software, manages to have had 10000 bugs for its 4 million lines of (hopefully system-abstract) source code, which puts it at having a bug in each ~400 SLOC. Windows Vista, a physical hardware operating system purportedly partly re-written from ground-up, is reported to have had about 30000 bugs and is 50 million SLOC, hence a bug in each ~1600 SLOC. When a desktop software has 4 times more bugs in the same volume of source code as an entire computer operating system, I say something is wrong with the former. Not to mention 4 million lines of code for a desktop environment - they either reinvented every little wheel there was to the system ("System libraries? We write that ourselves."), or their C++ -fu is way too fine-ground, perhaps more like assembly language even.
I am not defending Gnome, neither Vista. My point had to do solely with the fact that the bug count is way too high as for what KDE 4.3 is (desktop "environment" in its 4th evolution, written in C++).
This only proves my observation further. Imperative programming is just not a good way to produce high quality code, application regardless, and more so for larger projects, because we humans cannot be expected to make correct decisions on behalf of the machine all the time, most of the time. We often make small but often subtly fatal mistakes in the most mundane structures - loops, conditional statements, array organization etc - the most "boring" parts of the actual task programming, less often in actual task logic. And imperative programming, something most programmers do most of their time, is all about that - telling machine HOW to go about performing a task, not WHAT task to perform. You are bound to underestimate the performer constantly, when slavishly telling him not only what to do but also how to do it, every time, and sooner or later it will be evident how much the results suffer because the "programmer" assumes the performer is dumb, has no memory, cannot learn.
A question also - if we collectively had invested in more intelligent compiler research right from when it began to be possible (real memory/speed constraints), would software today be cheaper to produce and maintain, with regards to what bugs have cost both producers and consumers ever since? Such "more intelligent" compiler would refer to not-having to compromise on machine code efficiency when translating from VHLL (very high level language) source code, as opposed to from say C-like syntax, which in comparision would be LLL (low level langauge) - which otherwise is one of the reasons programmers prefer something in the middle of the tree - distrust to the dumb machine - "oh this can never be trusted to produce efficient code for me, I better do it all by hand with C". Which is oftentimes right even today. I mean, would Linux kernel be as efficient when written in ML or Haskell or Lisp?
To continue with that question - would the benefits of dealing with "behavioral" code and executing it outweigh the energy spent on compiler research and otherwise all those bugs? I think such "alternate timeverse" is not without merits indeed.
I think it is rather, all consumer software of sufficient complexity. My whole point was about workflow and tools used. In the end it is all about the bugs-per-line-of-code measure. I think NASA software is not the same as Gnome/KDE. However, it doesn't mean Gnome/KDE cannot adapt some of the useful NASA workflows.
If the project had more than 10000 bugs (let us face it - all bugs are never fixed), it is not worth anything. No matter what it is. Something is wrong with their coding. Probably way too imperative.
I believe the blame lies in the, umm how should I best call it, a sort of like "geologically active" field of science - I mean everybody is trying to create a perfect 3D renderer and perfect all they have, before they can settle in and start writing good stories. I truly believe this is one of the show-stoppers for developing good games. Look at it - just about every developer starts by actually REINVENTING the wheel here - make their own engine, and THEN build some game on top of it, while the engine actually gets more exposure. This is in our nature - we are divided between being storytellers and fantasts and on the other side being pragmatic scientists and mathematicians. In the old days the resources were so limited and the possibilities so inviting, many people created wonderful stories that captivated the gamers with their imaginary worlds, although executed on a much moderate plane of presentation. Today, it is like peeping through the keyhole into a world of ACTUAL possibilities - the hardware is so powerful, it just tickles all gaming studios to try and top the previous level of enslaving the machine - BEFORE they actually start thinking about storytelling. Think about it - you said it yourself - the hardware some years back, especially the hardware renderers - allowed for quite little innovation - it was all textures and polygons, and not many at that - few could break free of that prison, and even fewer tried, so almost every game looked the same. Of course I am generalizing, it is always possible to be creative using whatever resources at disposition, but let us consider the majority here - and they did not innovate much because everyone just saw those same polygons and that same DirectX. Nobody did voxels anymore for one - because we were past that "era" and the new era was all about hardware pipelines, but those were immature.
When we finally be getting freedom that true and mature raytracers will give us, along with good particle simulators and what not - maybe the creative potential will be inspired forth again. Until then, the new platform of creativity today may well be Adobe Flash platform - the 90s repeat themselves all over - not enough power to simulate reality but enough power to captivate gamers with good stories with useful execution.
Let me describe a useful analogy:
When a house alarm code is "guessed" by a thief, and the thief is caught, the media report, if any, usually does not include disclosing the code on your TV-screen in big letters along with instructions how you too can do it, as they cover the incident. Does it?
This is however much like what reality is for IT players. As soon as one person breaks into another partys authorization domain, he/she feels it is their democratic duty to let any and all others know how they can do the same. Disregarding any opinion the target party of the break-in may have about it. Why? Some twisted moral codex, mutated from reality into virtuality, I guess.
Yeah, I thought also that the information given by Allie in "Contact" is erroneous. I mean, there are just too many giveaway variables that would expose any attempt to "fake" such signal.
Also, if it is indeed as straightforward as you say it is to tune in to signals originating from the Moon (and I believe you know what you are talking about here) then I don't really get how the Moon hoax believers won't just shut up once and for all. I mean, there is skepticism, and then genuine paranoia and lack of common sense.
I believe in many UFOs to be of extraterrestrial origin and intelligent design by sentient species. But I don't subscribe to the theoretically possible but absurd (in light of circumstances) idea that Moon landings were faked. Don't they just have to point a dish at the Moon to finally unsubscribe from their disbelief? If so, why don't they do exactly that? Why make loads of websites with nice graphics and professor quotes, if all it takes is to actually do real scientific analysys of live data instead of digging into old archives and looking for anomalies?
Slashdot Mirror
I think it is fairly easy for a person who has sufficient relevant skills to differentiate between disassembled binary that was written by hand and a binary that was generated using less-intelligent machine like a compiler. This is the whole point of being able to "verify the claim". We humans can do that. Then again, if they used macros to generate their binaries, despite it being called "written in assembly", repetitive chunks of instructions are bound to pop-up, confusing humans even more. It is not like what I described is an easy job. But is a fairly doable, and for an expert - consider folks who reverse-engineer viruses and worms, etc. - it is even a profession. So yes, verifiable claim. If you see obviously stupid instruction sequences, which looked completely unoptimized, unless written by a kid who just started with assembly languages, you know probably a compiler has written that, and not a particularly intelligent one either. Also, the more disassembled code you have to look at, if we ignore the size of it as time-factor, the easier it is to give a definite conclusion on whether the code was written by hand by a human or generated by software where human was only supervising (= compiler usage scenario).
Taking into account what happens on Wikipedia sometimes - vandalism - I gotta say it occured to me that the percent of vandals re-writing and thus spoiling good articles goes down in proportion to the size of the public for the amount of pages said Wiki would contain. Simpler put, Wikipedia being a Wiki for the broadest possible public - the general public, no restrictions - is substantially more suspectible to vandalism than say a Wiki shared, written and accessed by 10 individuals (an intranet Wiki, for example). Add to that a relatively simple fact that probably any soldier with his sanity in behold will refrain from mal-editing Wiki entries on semi-automatic rifles because he knows he may be shot in the head by one held by his comrade - this makes the Army somewhat more of a unity than the general public, which generally does not care much for one another - everyone being anonymous and all. In the army, they would think twice before resorting to Wiki vandalism, because they know they may have to fight side by side, in which case you need all experience you can get from your buddies. The two factors should make for a very useful implementation indeed.
This what you get with 7 billion people on the planet. Over-worked worker bees. We all drink Gatorade, now time to give some to bees. No slacking off on this crowded rock!
Yes.
I hate to repeat myself, but here goes: don't give me that crap. And here is bonus line, since space is obviously so cheap here: gods forbid I ever attempt to write something like KDE in KDEs spirit.
Don't give me that crap.
True. The few times I used a MacBook I was pleasantly suprised how well OSX idles.
Thanks for correction. I never used Bootcamp, but I did assume (and obviously it does) it presents some sort of incompatibility for Windows running on a Mac. Probably it is Windows not having a good driver to interface Mac internals.
Hate to disagree with an expert but I have seen several cases where badly designed code directly affected battery. I am on Linux, and have got a habit of peeking into its source code, after checking with Intels "powertop" utility. Recently, I found out for example that ffmpeg uses a 1000hz timer to play a HTTP-delivered MP3 stream with bitrate of 56Kbps. Stuff like that. Of course not always it is due to bad code, but often it actually is.
Also, I do application software developing for a living, and in my case there has been minimal occurences where said manager actually came back and revised the software to include better powermanagement. Granted, they do exactly as you described - "let us first make it work". But after it is shipped, nobody cares for the code. Of course, many may say that I have been employed by really shitty managers/employers, and it would partially be true.
So, it is NOT JUST management. It is a multitude of factors, involving management AND coders. Both affect each other as well.
Faster and cheaper is the curse of our times. I hate that shit :-) I acknowledge its necessity in practical living, but it should be a temporary step on the way to "faster, cheaper, better" but it usually stops after the first two qualities are achieved.
The problem is not specific to Windows or MacBooks. Many developers code as if the only machines that will run their software are permanently el-grid-connected servers or workstations. Polling loops with insane timers (like 1000hz), and they also take the advice "don't optimize prematurely" to mean "don't optimize unless you are payed for it". Re-drawing the display even if it is not needed at all, copying data structures all over, etc. No wonder batteries drain.
In this case I believe all three are to blame - neither alone is the culprit - I mean Windows usually is compatible with real hardware enough to last couple-three hours on an average laptop battery doing average desktop stuff, MacBook is about the same. Probably BootCamp taking battery awareness too lightheartedly and/or unable to optimize for specific cases like virtualized Windows code running.
> pass uncovered
I meant 'unnoticed'. Dyslexia is getting worse...
Funny how it takes nothing short of an uproar to convince those marketing bozos to back down. Somehow, their morale is so crippled they cannot see on their own what is good and what is not. Time after time they try, trick after trick, to move the goal line as it benefits them. Darwin was right indeed - the environment you have to survive in (marketing dept. in this case) determines the kind of creature you are. When two groups are so segregated, that one sneaks in commercials in hope the trick will pass uncovered, and the other nervously ready to uproar at the slightest suspicion, this industry is so definitely not what it once was. There is war going on - customer vs. vendor. And that is okay, nothing new here. What is hilarious, how all vendors talk like they appreciate their customers, how the customer is always right and what not. Well, apparently it takes a very angry customer to convince them he is right. Everything else is considered an ambiguous signal, the machine does not interrupt the process.
I was blindly assuming I am posting in plain text, since I had personally set it up so in user preferences long ago. Which it now wasn't, probably because I flushed my cookies not long ago, even though I don't know if the actual preference is bound to the user profile or a separate cookie indeed. Was it so hard to understand what I was "rambling" about? You actually come across as more intelligent than many people here, who like to push sarcasm in front of their lack of relevant argument, which they do not even bother talking about, instead using Slashdot as a convenient place to spit out their unprocessed hate.
This is not a web-design forum. I was typing WITH paragraphs, if you have objections, direct them at whoever is responsible for resetting my "Post as" preference to "HTML formatted text" and whoever forbid editing posts. After that, you may look at the head of the page, it should bring you back to what the discussion is about.
If your attention span limits you to only comprehend three sentence posts with no lasting meaning, I guess you are part of the target KDE audience.
Forgot to mention that obligatory remark here: KDE is 4 million lines of source code; Windows these days is about 50 million (Windows Vista, acc. to Wikipedia); KDE 4.3, a subsequent version of a desktop software, manages to have had 10000 bugs for its 4 million lines of (hopefully system-abstract) source code, which puts it at having a bug in each ~400 SLOC. Windows Vista, a physical hardware operating system purportedly partly re-written from ground-up, is reported to have had about 30000 bugs and is 50 million SLOC, hence a bug in each ~1600 SLOC. When a desktop software has 4 times more bugs in the same volume of source code as an entire computer operating system, I say something is wrong with the former. Not to mention 4 million lines of code for a desktop environment - they either reinvented every little wheel there was to the system ("System libraries? We write that ourselves."), or their C++ -fu is way too fine-ground, perhaps more like assembly language even. I am not defending Gnome, neither Vista. My point had to do solely with the fact that the bug count is way too high as for what KDE 4.3 is (desktop "environment" in its 4th evolution, written in C++).
This only proves my observation further. Imperative programming is just not a good way to produce high quality code, application regardless, and more so for larger projects, because we humans cannot be expected to make correct decisions on behalf of the machine all the time, most of the time. We often make small but often subtly fatal mistakes in the most mundane structures - loops, conditional statements, array organization etc - the most "boring" parts of the actual task programming, less often in actual task logic. And imperative programming, something most programmers do most of their time, is all about that - telling machine HOW to go about performing a task, not WHAT task to perform. You are bound to underestimate the performer constantly, when slavishly telling him not only what to do but also how to do it, every time, and sooner or later it will be evident how much the results suffer because the "programmer" assumes the performer is dumb, has no memory, cannot learn. A question also - if we collectively had invested in more intelligent compiler research right from when it began to be possible (real memory/speed constraints), would software today be cheaper to produce and maintain, with regards to what bugs have cost both producers and consumers ever since? Such "more intelligent" compiler would refer to not-having to compromise on machine code efficiency when translating from VHLL (very high level language) source code, as opposed to from say C-like syntax, which in comparision would be LLL (low level langauge) - which otherwise is one of the reasons programmers prefer something in the middle of the tree - distrust to the dumb machine - "oh this can never be trusted to produce efficient code for me, I better do it all by hand with C". Which is oftentimes right even today. I mean, would Linux kernel be as efficient when written in ML or Haskell or Lisp? To continue with that question - would the benefits of dealing with "behavioral" code and executing it outweigh the energy spent on compiler research and otherwise all those bugs? I think such "alternate timeverse" is not without merits indeed.
I think it is rather, all consumer software of sufficient complexity. My whole point was about workflow and tools used. In the end it is all about the bugs-per-line-of-code measure. I think NASA software is not the same as Gnome/KDE. However, it doesn't mean Gnome/KDE cannot adapt some of the useful NASA workflows.
If the project had more than 10000 bugs (let us face it - all bugs are never fixed), it is not worth anything. No matter what it is. Something is wrong with their coding. Probably way too imperative.
I believe the blame lies in the, umm how should I best call it, a sort of like "geologically active" field of science - I mean everybody is trying to create a perfect 3D renderer and perfect all they have, before they can settle in and start writing good stories. I truly believe this is one of the show-stoppers for developing good games. Look at it - just about every developer starts by actually REINVENTING the wheel here - make their own engine, and THEN build some game on top of it, while the engine actually gets more exposure. This is in our nature - we are divided between being storytellers and fantasts and on the other side being pragmatic scientists and mathematicians. In the old days the resources were so limited and the possibilities so inviting, many people created wonderful stories that captivated the gamers with their imaginary worlds, although executed on a much moderate plane of presentation. Today, it is like peeping through the keyhole into a world of ACTUAL possibilities - the hardware is so powerful, it just tickles all gaming studios to try and top the previous level of enslaving the machine - BEFORE they actually start thinking about storytelling. Think about it - you said it yourself - the hardware some years back, especially the hardware renderers - allowed for quite little innovation - it was all textures and polygons, and not many at that - few could break free of that prison, and even fewer tried, so almost every game looked the same. Of course I am generalizing, it is always possible to be creative using whatever resources at disposition, but let us consider the majority here - and they did not innovate much because everyone just saw those same polygons and that same DirectX. Nobody did voxels anymore for one - because we were past that "era" and the new era was all about hardware pipelines, but those were immature. When we finally be getting freedom that true and mature raytracers will give us, along with good particle simulators and what not - maybe the creative potential will be inspired forth again. Until then, the new platform of creativity today may well be Adobe Flash platform - the 90s repeat themselves all over - not enough power to simulate reality but enough power to captivate gamers with good stories with useful execution.
while men remain as aesthetically unappealing as their caveman ancestors
Good news everybody! We still rock!
I split the energy fifty-fifty
Everyone can change their password back to 'trustno1' now
I juz like changed my MySpace passwurd like you said, what do I do now? Luuulz! O.o
Let me describe a useful analogy: When a house alarm code is "guessed" by a thief, and the thief is caught, the media report, if any, usually does not include disclosing the code on your TV-screen in big letters along with instructions how you too can do it, as they cover the incident. Does it? This is however much like what reality is for IT players. As soon as one person breaks into another partys authorization domain, he/she feels it is their democratic duty to let any and all others know how they can do the same. Disregarding any opinion the target party of the break-in may have about it. Why? Some twisted moral codex, mutated from reality into virtuality, I guess.
You worry about your signature, I'll worry about those posts.
Yeah, I thought also that the information given by Allie in "Contact" is erroneous. I mean, there are just too many giveaway variables that would expose any attempt to "fake" such signal.
Also, if it is indeed as straightforward as you say it is to tune in to signals originating from the Moon (and I believe you know what you are talking about here) then I don't really get how the Moon hoax believers won't just shut up once and for all. I mean, there is skepticism, and then genuine paranoia and lack of common sense.
I believe in many UFOs to be of extraterrestrial origin and intelligent design by sentient species. But I don't subscribe to the theoretically possible but absurd (in light of circumstances) idea that Moon landings were faked. Don't they just have to point a dish at the Moon to finally unsubscribe from their disbelief? If so, why don't they do exactly that? Why make loads of websites with nice graphics and professor quotes, if all it takes is to actually do real scientific analysys of live data instead of digging into old archives and looking for anomalies?