Your code shouldn't have high coupling, neither should the UI. Organized by role/user, by usage, the UI probably doesn't need to let your users do super-cross-functional things in the same bit of screen real-estate. If the UI does need to let your users do super-cross-functional things in the same bit of screen real-estate then the coupling is really just cohesion + complexity, deal with it.
If you can get rid of UI coupling, you only need subsets of the UI team on the reviews.
And you'll end up adding in UI cohesion while you shake the UI design around.
So separate the bits and find a way to reuse your UI elements, at the very least reuse-by-usage across different role/users (so people can graduate to power user without re-learning your UI).
"...pretty much everything you would expect from a robust language."
But missing the most rudimentary functionality to support safe resource aquisition and release. References to objects in Object Pascal/Delphi are always by object pointers to objects which are allocated on the heap. When these references go out of scope, no action is taken, no destructors or deleters are called (except the hackery made for interfaces). The result is a nasty repetition of try/finally blocks for any function/method/procedure which will use an object with limited lifetime.
It's sad that in a language marketed for rapid application development, it's easier to leak memory than in C++.
What AMD appears to be trying isn't the same as superscalar processing, but it might run into a similar problem.
Where superscalar requires a good dispatcher to minimize branch prediction misses, AMD appears to be making decisions, not about dispatch, but about how to do locking of shared memory (think critical sections).
Re:We just got tired of being insulted
on
Demise of C++?
·
· Score: 1
*smiles* C++ is a languages in which it is possible--albeit complex--to overcome the language's own limitations and express things with nearly the beauty of Lisp.
No source considers WinCE to be a hard real-time OS. There are realtime extensions to embedded windows (WinCE and XPe) available, and some even sound pretty promising from a technical standpoint, but the bottom line is that with a non-deterministic scheduler, it's not real-time. Usually predictable, sure. Probably fast enough, of course; however, without the extensions (and perhaps in some situations with them, the technical articles I've seen were still pretty vague in spots) it's not an RTOS, and please... if anyone is going to use it behind some bit of critical hardware, put the stickers on the outside so I'll be able to avoid trusting my life to it *smirks*
The ease with which people seemed to be eluding the anti-counterfeiting software left some wondering why Adobe had included it in the first place.
The answer to this wonderful question is knowable through the simple process of "Ancedotal Induction."
At some point during the development of the mentioned version of the application, someone in product management induced a design constraint along the lines of "don't enable counterfeiters." None of the other product managment types cared because "we'll get that for free from the Central Bank Counterfeit Deterrence Group."
Product managmeent gave this new design constraint to a behind-schedule-implementation-manager. This poor guy said "sure", because, well... they're paid to agree with product managment. Especially since it was something "we'll get for free from the Central Bank Counterfeit Deterrence Group."
So the behind-schedule-implementation-manager went to the engineering team and said "we need to add counterfeit deterrence, give me the schedule impact, but I've already decided it shouldn't take _any_ time at all, because we'll get it for free from the Central Bank Counterfeit Deterrence Group."
The engineers decided immediately that actual counterfeit deterrence would require software slightly more capable than the average bartender, and that there was no good place in the image processing design to hook in something like that anyway. However, since it wasn't their code that'd take the blame when it didn't work... who cares. They told the implementation manager that it'd add as many hours to the schedule as they were currently behind and went back to work.
Eventually, the component (let's be realistic: an old version of a dll, and the wrong typelib, and a corrupted Word document claiming to be the "design document and manual) shows up in an engineer's inbox. He hacks it in on a branch to one part of the image import processing logic, fires up the build, and doesn't see it crash. It gets merged back to the main line immediately.
The last it was ever heard from before shipping was when someone from the test team called some friends over to "hey, look at this"--whereupon he showed them that you could get really good quality images of currency... but only if you used the "raw" settings from the twain image capture page.
ClearCase is another one of those products where the behaviour is not safe. For example, if you find that another person has checked out a file, then you can check it out "unreserved". When you go to check back in a large batch of files, it checks them all back in except for the code that was unreserved (it's that remembering state thing again). So the net effect is that the code under source code control can't compile. CVS is free and has this facility: why should we pay a premium to make our code base unstable?
This overly general statement kills the article for me. I have the pleasure to use a superbly-maintained clearcase system daily (no, I'm not the administrator, just a happy customer), and must disagree. So I'll do so:
"ClearCase is another one of those products where the behaviour is not safe." The author has mentioned one other version control system at this point in the article, and specifically states that it was an administration problem which made the system unsafe. Perhaps revision control systems _are_ database systems (yes, yes, they are), and like other complex databases deserve a competant administrator.
"For example, if you find that another person has checked out a file, then you can check it out 'unreserved'." First, if multiple people are working in a Clearcase environment, and they are working on overlapping or dependent file sets, then they should be working on different branches from a known label point on an integration branch, only use that deviates from this best practice would ever find that a file was checked out by another. In addition, 'unreserved' checkouts require that the file be merged when it is checked in with changes, if the developer can't create the merge properly, they shouldn't have checked the file out in the first place.
"When you go to check back in a large batch of files...." Why would you have a "large batch of files" checked out to begin with? Correctly structuring your branch structure allows each developer to make multiple check-ins as they work, providing not _just_ named-version tracking, but also fine-grained control (Ever wished you could back out that change you made just the other morning, don't remember what you did before? Use a well implemented version control scheme). Again, blaming what seems to be poor setup and management of your version control system is hardly the answer.
Certainly, there are complexities to working with a version control system, a system that maintains both position in the directory structure and versions over time deserves competant setup, administration, user-instruction, and users. If those are missing (and it seems that they are in the author's situation), then head back to the luddite's favorite method: "foo.c.1"
When describing a state as an entity capable of ethical (or unethical) behavior, eventually the recently held concept of a group psuedo-person, so inflated by corporations breaks down and "the buck stops somewhere". With that culpability must come the ability to make choice.
In allowing that a state has that ability, you allow that as a consumer the state may make any decision they find necessary. The state's decision that they will only purchase an open source product is immediately defensible from a source-escrow point of view, if you happen to live in that state, and you disagree, do something about it. The "state" is no moral entity, as the electorate, fix the problem if you find one, however, getting hot about source avaiability, inspectability, and free adaptation is a bit silly.
If this becomes commonplace, I can finally see paying "Only $50 usd to leverage your site through our search engine submission program. Submit your site to...." Then just list a bunch of amusingly wrong links on the page, bingo poisoned searches. Mind you, google gets my exemption, but the new MS search engine effort...
Job was a later novel, and the short biography on the society's page points out that it was one of his first "back on his game" novels after a period of some serious health problems:
Several years ago a blocked artery led to oxygen starvation in part of his brain, with a resulting decline in the quality of his work. The blockage was finally repaired by a new technique in brain surgery.
"Mr. Heinlein says he realized he needed the operation when his wife and primary editor, Virginia, told him a new novel was a failure. He dotes on Virginia, whom he met while they were both in the Navy, and he credits her with his understanding of the market system. 'She cured me. I'd gotten fed up with the New Deal by 1938, but I was still trying to save the world, suffering from that nasty itch that characterizes socialists -- the sort of thing that makes them think that everything should be prevented or required.'
"The high quality of JOB: A COMEDY OF JUSTICE (1984) is evidence that the bypass was successful. And the author is undaunted by his ailments. Two years ago he went with Virginia on a Spartan cruise to the Antarctic, and last year the Heinleins went to the other end of the world, on a cruise that navigated the Northwest Passage.
Regardless, the following line of the post raised a blip on whatever passes for my interest.
Those concerned that it's not a good idea for computers to track their belongings and whereabouts are advised that they may ultimately have to fragment their identities, keeping multiple IDs and e-mail addresses
Naturally, I'm posting before reading the article (What, you fools, it's the blog for god's sake, knee-jerking is required; just call it "immediate reaction commentary" and pass it off as a "feature" of blogging.); but regardless of the article author's position on identity fragmentation, an important fact leaks out in the statement.
If trackers expect, and adjust for identity fragmentation by tracked, then they are likely to ultimately rely on measures built by society to avoid identity theft for purposes of their tracking (For example, determining that fooyoutrackingguys@hotmail.com is also bararegularguy@hotmail.com would be beneficial for whatever purposes the original tracking and correllation system was intended for. Determining that the fragmented identities represented by those monikers are in fact one identity by appealing to data that may not be legally falsified by the identity creator is likely. Think about the real reason companies ask for a US customer's SSN if they can). The ability of the trackers to appeal to a legal device that the tracked may not falsely state clearly gives an advantage in the "identity fragmentation game" to the trackers.
But everyone knows that.
The real question is, in the hue-and-cry for legislating barriers to identity theft, will any rights to non-fraudulent identity fragmentation be protected?
Brought to you by the/. crowd, the answer: "Of course not! In Soviet Ru^H^H^H America, the usenet posts you"
The answer's obvious. SCO & IBM realized that eventually the "licensed but not owned" model will kill open source, and leave only a few ugly redmondites scrambling around on the dead shells of what could have been the best software to grace the planet. They got pissed.
what better way out than to invalidate the whole concept of "licensed but not owned" property in a huge legal farce. IBM devastates SCO, the supreme court eventually invalidates the concept of licensed but not owned property, IBM buys SCO in a show of reciprocal niceness, and they start making serious money selling "software that you'll own" under the GPL 3.Next.
Oh, and somewhere in the underhells of RedMSond, a demon dies a painful death. Heh.
It comes down to a simple thought: Sure, I'd love it if everyone who wanted my creative output would pay for it, but enough will, even without a draconian copyright solution, or at least they'll pay for my surrounding knowledge.
Regardless, copyright to protect an idea is silly. If I have an idea, and you have an idea, we both still have an idea. Excellent how it works like that. Even better, since I'm me, I get to keep having ideas.
The intelligent and creative minority have nothing to fear from free exchange of ideas.
As unsettling as I find this, I also find it appropriate.
History has always demarked a division between civilians and military, both in the traditions of service, and deeper, in the psyche. Plato demarked the guardian's education as beginning with fiction [337a]. And it was a key to this education that it twisted the basic nature of those who would be guardians, demarking them mentally from the populace. This is a key concept in the training of warriors that has survived in literature and drama through the ages (in our time, you need only see the unifying concepts behind group-identity put forward in studies of the German troops of WWII, or Card's work, let alone the psych studies that _do_ point out a greater tendancy to follow orders and act cohesively with a rigorous group-constructed identity).
Is it any wonder that a society adept at mass production would find ways to mass produce those things that still must be men and not machines?
Is this a criticism of the men and women who serve? By no means. The psychological conditioning they receive is no less responsible for their survival and success than their physical training.
Is it grounds for a critique of an immature, and childlike race (mankind) who still finds war regrettably necessary? Perhaps. At least, however, it's highly unlikely that the children of those so trained will value war as highly as we do today.
6) While you're at it, discourage respect for law in every possible way. This will dissolve the glue that holds the nation together, and dissuade any long-term thinking. Societies in which the law can be clearly seen to apply to some and not to others are doomed to decay, in terms of innovation and everything else.
And now for an addendum
6a. Specifically construct laws so riddled with inaccuracy of purpose, incomprehensibility of intent, impossibility of execution, immorality of effect, and plain lack of common sense, that everyone is criminalized equally, and proven innocent $ub$antially due to their per$onal $olvency. Particularly good results may be achieved if the laws in question are ignored as technicalities by the traditionally moral masses.
inspiration for this post, and the poster believes the original article, was gained largely through understanding the logical basis of the works of Ayn Rand, all credit as it is due
I have to admit, it's probably me. As I understand it, the article points out that there exist designs for data-collection and data-mining that would allow non-disclosure of personal information. True, the public/business could use these designs when constructing data-collection systems.
However, posters have rightly pointed out that mandates to "all your data belong to us" by the Gvt will probably either explicitly cover the case "you must be able to turn over all your data, don't design it otherwise", or they will implicitly cover the case "failure turn over all the data will result in a fine". Almost certainly, the second statement is easier for the voting public to accept than the first. In either case, the same result obtains: The designs utilized will be the easiest ones, the ones in use today, and those are the ones that provide simple, bi-directional links between John Doe and his pr0n/weapons/libertarian-prose purchasing behavior.
Surely, it is in some sense more seemly to collect the minimal data required, and to store it in such a way that the system itself maintains user privacy quite aside from the database's access permissions; however, in light of the technology barriers (it's _harder_ to implement such a system, and harder during the classically shorted design phase), and the possible future legislative barriers, it seems unlikely in the extreme that these protections will make it into most systems of this kind.
At the root, our loss of privacy protections is a societal/legal matter. Slashdot maintains firmly that piracy issues (societal/behavioral matter) can't be solved by technology (DRM), don't be so quick to embrace the thought that privacy protection could possibly be so solved.
It must be the case that these things (the author points to his tinfoil hat) are indeed selling well. I can only guess that the market must be a bit flooded by the lead variety, soemone's obviously having their brain addled.
At any rate, this great example of a false dilemma fallacy may have a point to make, assuming that, the worth of a network lies in its connectivity and that restrictions on that connectivity invariably decrease the worth of the network. The article presents (at most) the one lucid point: The US is increasingly guilty of restricting the connectivity of this network.
Admittedly, this point could have been garnered in something like the first three lines of the article, and if you did so, considering the rest to be sub-literate, self-contridictory drivel, more power to you.
For the majority of/.'rs living in the US, the message is simple: Your Congress-critters, and other quasi-elected officials are making you look bad to such a degree that you're being disabused in bad prose from other countries. Well, let's get rid of the source of the problem asap.
It sounds like the interesting possibility almost grasped here is the possibility of producing a self-customized layout on the fly.
hook the keyboard driver and tokenize input into words (corrections included where possible), feed through a spell-checker (to find what word was likely the target), and re-insert as input through the algorithm. Admittedly, this makes it more of a neural-net than a GA, but it is continuously evolving, and eventually, you should even out on the best keyboard layout for what you type on a daily basis
I expect my '_' key to end up somewhere on the home row in a couple of weeks (programming = bad typing habits)
Blockquoth the poster, evermore (from here until the ending blockquote tag):
Ultimately the neural network correctly predicted injuries 84 percent of the time, Meersseman said. "The mathematicians think they can get this number up to 96 percent," he added
This is about the funniest line I've read today (and today they almost gave the coding staff control of the functional requirements specifications....). Of course the mathematicians think they can get the beast more accurate. Everyone knows
The statisticians believed the odds quoted because they thought them to be grounded in theory established; the physicists believed the odds quoted because they thought them to be grounded in observation.... Only murphy knew the truth.
Well.... Damn, it's about time I heard this viewpoint.
Let's just say, that as a somewhat interested code-monkey, I've been wondering off and on now about a bit of what the following answer touches on
Blockquoth the poster (evermore till the/BLOCKQUOTE, with emphasis added):
3) Microsoft.NET and Linux by SL33Z3
What are your feelings on Microsoft's.NET and any initiatives to make the technology work on Linux?
Alan:
Microsoft has publically stated that it has patents on critical parts of.NET and will enforce them. If you think that.NET is a good idea, or cloning.NET is a good idea, remember you won't have a US market unless they find you amusing enough to allow to live on. And if you think Microsoft can be trusted on this look at their recent activities against Samba.
The system itself is mildly interesting as a technology. Its yet another virtual machine, roughly equivalent to picojava in capabilities. It has an interesting way to self generate IDL, but one which their own papers say cannot represent all programming languages.
The more dangerous parts of all this are not so much.NET but chunks of the model that not only the.NET product and the Java standards rely on. Things like xmlrpc, soap and the stuff on top of them are designed to "interwork through firewalls". A better phrase would be "go through the firewall like a knife through butter in a way that prevents the companies involved monitoring the activity".
When all you have is an encrypted SSL session how are you going to figure out if its a legitimate bit of ebusiness with a related company or someone in your company uploading your entire company customer database?
So, I'm mostly curious. Is the whole XMLRPC, SOAP, Web-Based Client, Firewall circle self driving? Network administrators started putting up firewalls so that undesireable traffic would go no further. Then the *.net busted onto the scene and port 80 sort of popped right open pretty much everywhere. Now we write complicated schemes (and schemas) and wrap all our data into a session-oriented layer on top of a connectionless protocol, and shuttle it out (often, as noted in the quote, with great encryption) across the ubiquitously open ports.
To what end? We've essentially arrived at a multipurpose protocol layered atop a single purposed sub-section of a multipurposed protocol, the firewall vendors make the bank, the network admins get a bit more automated every day, and all that's old is new again.
Slashdot Mirror
Your code shouldn't have high coupling, neither should the UI. Organized by role/user, by usage, the UI probably doesn't need to let your users do super-cross-functional things in the same bit of screen real-estate. If the UI does need to let your users do super-cross-functional things in the same bit of screen real-estate then the coupling is really just cohesion + complexity, deal with it.
If you can get rid of UI coupling, you only need subsets of the UI team on the reviews.
And you'll end up adding in UI cohesion while you shake the UI design around.
So separate the bits and find a way to reuse your UI elements, at the very least reuse-by-usage across different role/users (so people can graduate to power user without re-learning your UI).
"...pretty much everything you would expect from a robust language."
But missing the most rudimentary functionality to support safe resource aquisition and release. References to objects in Object Pascal/Delphi are always by object pointers to objects which are allocated on the heap. When these references go out of scope, no action is taken, no destructors or deleters are called (except the hackery made for interfaces). The result is a nasty repetition of try/finally blocks for any function/method/procedure which will use an object with limited lifetime.
It's sad that in a language marketed for rapid application development, it's easier to leak memory than in C++.
What AMD appears to be trying isn't the same as superscalar processing, but it might run into a similar problem.
b leCheckedLocking.html shows the problem, which already is an issue on 64-bit hardware).
Where superscalar requires a good dispatcher to minimize branch prediction misses, AMD appears to be making decisions, not about dispatch, but about how to do locking of shared memory (think critical sections).
Critical section prediction might prove less expensive than branch prediction in practice even if they are similar in theory (http://www.cs.umd.edu/~pugh/java/memoryModel/Dou
*smiles* C++ is a languages in which it is possible--albeit complex--to overcome the language's own limitations and express things with nearly the beauty of Lisp.
LATFW/
, 46,934
http://archive.gp2x.de/cgi-bin/cfiles.cgi?0,0,0,0
http://www.boost.org/libs/python/doc/
You really don't mean C
You really mean C++'s C-compatible subset
Completely worth it for the boost-python interface
Soap, Ballot, Ammo; yes, of course.
Unfortunately the first use must often be in reverse order.
No source considers WinCE to be a hard real-time OS. There are realtime extensions to embedded windows (WinCE and XPe) available, and some even sound pretty promising from a technical standpoint, but the bottom line is that with a non-deterministic scheduler, it's not real-time. Usually predictable, sure. Probably fast enough, of course; however, without the extensions (and perhaps in some situations with them, the technical articles I've seen were still pretty vague in spots) it's not an RTOS, and please... if anyone is going to use it behind some bit of critical hardware, put the stickers on the outside so I'll be able to avoid trusting my life to it *smirks*
Thank god there was someone reading with some sense.
The answer to this wonderful question is knowable through the simple process of "Ancedotal Induction."
At some point during the development of the mentioned version of the application, someone in product management induced a design constraint along the lines of "don't enable counterfeiters." None of the other product managment types cared because "we'll get that for free from the Central Bank Counterfeit Deterrence Group."
Product managmeent gave this new design constraint to a behind-schedule-implementation-manager. This poor guy said "sure", because, well... they're paid to agree with product managment. Especially since it was something "we'll get for free from the Central Bank Counterfeit Deterrence Group."
So the behind-schedule-implementation-manager went to the engineering team and said "we need to add counterfeit deterrence, give me the schedule impact, but I've already decided it shouldn't take _any_ time at all, because we'll get it for free from the Central Bank Counterfeit Deterrence Group."
The engineers decided immediately that actual counterfeit deterrence would require software slightly more capable than the average bartender, and that there was no good place in the image processing design to hook in something like that anyway. However, since it wasn't their code that'd take the blame when it didn't work... who cares. They told the implementation manager that it'd add as many hours to the schedule as they were currently behind and went back to work.
Eventually, the component (let's be realistic: an old version of a dll, and the wrong typelib, and a corrupted Word document claiming to be the "design document and manual) shows up in an engineer's inbox. He hacks it in on a branch to one part of the image import processing logic, fires up the build, and doesn't see it crash. It gets merged back to the main line immediately.
The last it was ever heard from before shipping was when someone from the test team called some friends over to "hey, look at this"--whereupon he showed them that you could get really good quality images of currency... but only if you used the "raw" settings from the twain image capture page.
Next stop
This overly general statement kills the article for me. I have the pleasure to use a superbly-maintained clearcase system daily (no, I'm not the administrator, just a happy customer), and must disagree. So I'll do so:
"ClearCase is another one of those products where the behaviour is not safe." The author has mentioned one other version control system at this point in the article, and specifically states that it was an administration problem which made the system unsafe. Perhaps revision control systems _are_ database systems (yes, yes, they are), and like other complex databases deserve a competant administrator.
"For example, if you find that another person has checked out a file, then you can check it out 'unreserved'." First, if multiple people are working in a Clearcase environment, and they are working on overlapping or dependent file sets, then they should be working on different branches from a known label point on an integration branch, only use that deviates from this best practice would ever find that a file was checked out by another. In addition, 'unreserved' checkouts require that the file be merged when it is checked in with changes, if the developer can't create the merge properly, they shouldn't have checked the file out in the first place.
"When you go to check back in a large batch of files...." Why would you have a "large batch of files" checked out to begin with? Correctly structuring your branch structure allows each developer to make multiple check-ins as they work, providing not _just_ named-version tracking, but also fine-grained control (Ever wished you could back out that change you made just the other morning, don't remember what you did before? Use a well implemented version control scheme). Again, blaming what seems to be poor setup and management of your version control system is hardly the answer.
Certainly, there are complexities to working with a version control system, a system that maintains both position in the directory structure and versions over time deserves competant setup, administration, user-instruction, and users. If those are missing (and it seems that they are in the author's situation), then head back to the luddite's favorite method: "foo.c.1"
When describing a state as an entity capable of ethical (or unethical) behavior, eventually the recently held concept of a group psuedo-person, so inflated by corporations breaks down and "the buck stops somewhere". With that culpability must come the ability to make choice.
In allowing that a state has that ability, you allow that as a consumer the state may make any decision they find necessary. The state's decision that they will only purchase an open source product is immediately defensible from a source-escrow point of view, if you happen to live in that state, and you disagree, do something about it. The "state" is no moral entity, as the electorate, fix the problem if you find one, however, getting hot about source avaiability, inspectability, and free adaptation is a bit silly.
Heh.
If this becomes commonplace, I can finally see paying "Only $50 usd to leverage your site through our search engine submission program. Submit your site to...." Then just list a bunch of amusingly wrong links on the page, bingo poisoned searches. Mind you, google gets my exemption, but the new MS search engine effort...
That's from http://www.heinleinsociety.org/conservativeview.h
Regardless, the following line of the post raised a blip on whatever passes for my interest.
Naturally, I'm posting before reading the article (What, you fools, it's the blog for god's sake, knee-jerking is required; just call it "immediate reaction commentary" and pass it off as a "feature" of blogging.); but regardless of the article author's position on identity fragmentation, an important fact leaks out in the statement.
If trackers expect, and adjust for identity fragmentation by tracked, then they are likely to ultimately rely on measures built by society to avoid identity theft for purposes of their tracking (For example, determining that fooyoutrackingguys@hotmail.com is also bararegularguy@hotmail.com would be beneficial for whatever purposes the original tracking and correllation system was intended for. Determining that the fragmented identities represented by those monikers are in fact one identity by appealing to data that may not be legally falsified by the identity creator is likely. Think about the real reason companies ask for a US customer's SSN if they can). The ability of the trackers to appeal to a legal device that the tracked may not falsely state clearly gives an advantage in the "identity fragmentation game" to the trackers.
But everyone knows that.
The real question is, in the hue-and-cry for legislating barriers to identity theft, will any rights to non-fraudulent identity fragmentation be protected?
Brought to you by the
Hell yes.
The answer's obvious. SCO & IBM realized that eventually the "licensed but not owned" model will kill open source, and leave only a few ugly redmondites scrambling around on the dead shells of what could have been the best software to grace the planet. They got pissed.
what better way out than to invalidate the whole concept of "licensed but not owned" property in a huge legal farce. IBM devastates SCO, the supreme court eventually invalidates the concept of licensed but not owned property, IBM buys SCO in a show of reciprocal niceness, and they start making serious money selling "software that you'll own" under the GPL 3.Next.
Oh, and somewhere in the underhells of RedMSond, a demon dies a painful death. Heh.
It comes down to a simple thought: Sure, I'd love it if everyone who wanted my creative output would pay for it, but enough will, even without a draconian copyright solution, or at least they'll pay for my surrounding knowledge.
Regardless, copyright to protect an idea is silly. If I have an idea, and you have an idea, we both still have an idea. Excellent how it works like that. Even better, since I'm me, I get to keep having ideas.
The intelligent and creative minority have nothing to fear from free exchange of ideas.
As unsettling as I find this, I also find it appropriate.
History has always demarked a division between civilians and military, both in the traditions of service, and deeper, in the psyche. Plato demarked the guardian's education as beginning with fiction [337a]. And it was a key to this education that it twisted the basic nature of those who would be guardians, demarking them mentally from the populace. This is a key concept in the training of warriors that has survived in literature and drama through the ages (in our time, you need only see the unifying concepts behind group-identity put forward in studies of the German troops of WWII, or Card's work, let alone the psych studies that _do_ point out a greater tendancy to follow orders and act cohesively with a rigorous group-constructed identity).
Is it any wonder that a society adept at mass production would find ways to mass produce those things that still must be men and not machines?
Is this a criticism of the men and women who serve? By no means. The psychological conditioning they receive is no less responsible for their survival and success than their physical training.
Is it grounds for a critique of an immature, and childlike race (mankind) who still finds war regrettably necessary? Perhaps. At least, however, it's highly unlikely that the children of those so trained will value war as highly as we do today.
And now for an addendum
6a. Specifically construct laws so riddled with inaccuracy of purpose, incomprehensibility of intent, impossibility of execution, immorality of effect, and plain lack of common sense, that everyone is criminalized equally, and proven innocent $ub$antially due to their per$onal $olvency. Particularly good results may be achieved if the laws in question are ignored as technicalities by the traditionally moral masses.
inspiration for this post, and the poster believes the original article, was gained largely through understanding the logical basis of the works of Ayn Rand, all credit as it is due
*throwing hands into the air*
I have to admit, it's probably me. As I understand it, the article points out that there exist designs for data-collection and data-mining that would allow non-disclosure of personal information. True, the public/business could use these designs when constructing data-collection systems.
However, posters have rightly pointed out that mandates to "all your data belong to us" by the Gvt will probably either explicitly cover the case "you must be able to turn over all your data, don't design it otherwise", or they will implicitly cover the case "failure turn over all the data will result in a fine". Almost certainly, the second statement is easier for the voting public to accept than the first. In either case, the same result obtains: The designs utilized will be the easiest ones, the ones in use today, and those are the ones that provide simple, bi-directional links between John Doe and his pr0n/weapons/libertarian-prose purchasing behavior.
Surely, it is in some sense more seemly to collect the minimal data required, and to store it in such a way that the system itself maintains user privacy quite aside from the database's access permissions; however, in light of the technology barriers (it's _harder_ to implement such a system, and harder during the classically shorted design phase), and the possible future legislative barriers, it seems unlikely in the extreme that these protections will make it into most systems of this kind.
At the root, our loss of privacy protections is a societal/legal matter. Slashdot maintains firmly that piracy issues (societal/behavioral matter) can't be solved by technology (DRM), don't be so quick to embrace the thought that privacy protection could possibly be so solved.
It must be the case that these things (the author points to his tinfoil hat) are indeed selling well. I can only guess that the market must be a bit flooded by the lead variety, soemone's obviously having their brain addled.
/.'rs living in the US, the message is simple: Your Congress-critters, and other quasi-elected officials are making you look bad to such a degree that you're being disabused in bad prose from other countries. Well, let's get rid of the source of the problem asap.
At any rate, this great example of a false dilemma fallacy may have a point to make, assuming that, the worth of a network lies in its connectivity and that restrictions on that connectivity invariably decrease the worth of the network. The article presents (at most) the one lucid point: The US is increasingly guilty of restricting the connectivity of this network.
Admittedly, this point could have been garnered in something like the first three lines of the article, and if you did so, considering the rest to be sub-literate, self-contridictory drivel, more power to you.
For the majority of
It sounds like the interesting possibility almost grasped here is the possibility of producing a self-customized layout on the fly.
hook the keyboard driver and tokenize input into words (corrections included where possible), feed through a spell-checker (to find what word was likely the target), and re-insert as input through the algorithm. Admittedly, this makes it more of a neural-net than a GA, but it is continuously evolving, and eventually, you should even out on the best keyboard layout for what you type on a daily basis
I expect my '_' key to end up somewhere on the home row in a couple of weeks (programming = bad typing habits)
This is about the funniest line I've read today (and today they almost gave the coding staff control of the functional requirements specifications....). Of course the mathematicians think they can get the beast more accurate. Everyone knows
The statisticians believed the odds quoted because they thought them to be grounded in theory established; the physicists believed the odds quoted because they thought them to be grounded in observation.... Only murphy knew the truth.
Let's just say, that as a somewhat interested code-monkey, I've been wondering off and on now about a bit of what the following answer touches on
Blockquoth the poster (evermore till the
So, I'm mostly curious. Is the whole XMLRPC, SOAP, Web-Based Client, Firewall circle self driving? Network administrators started putting up firewalls so that undesireable traffic would go no further. Then the *.net busted onto the scene and port 80 sort of popped right open pretty much everywhere. Now we write complicated schemes (and schemas) and wrap all our data into a session-oriented layer on top of a connectionless protocol, and shuttle it out (often, as noted in the quote, with great encryption) across the ubiquitously open ports.
To what end? We've essentially arrived at a multipurpose protocol layered atop a single purposed sub-section of a multipurposed protocol, the firewall vendors make the bank, the network admins get a bit more automated every day, and all that's old is new again.
Wierd.
You people kill me laughing