If it was so easy as you suggest then it would be in use right now. However, it's not.
That it's not, is obvious by observation. That it can be easy, is possible given the right "tools". That even if it were easy implies we would be using it, simply does not follow. There are many factors influencing popularity, and as we all know, "the best" does not always win.
It's not that it is impossible to write 100% perfect software but it might as well be due to the limitations of humans.
It is undoubtedly due to the limitations of humans. Our limitations is the entire point of abstraction, and why it's such a powerful organizing principle for humans: it reduces the complexity of a system to a well-defined, locally causal set of interactions (the interface). The more powerful the abstraction, the more likely the software constructed from it is correct.
This is why strong type systems, functional programming idioms, algebraic data types, modules, etc. yield software that is very close to "correct by construction": they are powerful abstraction mechanisms that are understandable by humans, yet still reasonably efficient. Unfortunately, they are not as popular, and not for any technical deficiency (though that may have been true at some point), but mostly by inertia.
If a god existed, and its creation did have a purpose, why disguise the purpose? Why not have it explicitly available to all sentient beings?
Come on, the answer to this is trivial. For all we know, we're simply an anthropological experiment or simulation by some advanced civilization, whose express purpose is to see how long it takes us to figure that fact out.
However, the physical evidence is there, and many of us belive God does not lie in either nature or in scripture.
Then the other question you have to ask yourself is, "what makes scripture the word of God?" Ultimately, the only answer is faith, and if you choose to believe something with no evidence, I don't see how you can ever hope to reconcile this with a philosophy that requires evidence before belief. All you end up doing is fitting facts to your interpretation.
As a famous physicist once said, "You're not even wrong". There are plenty of software architectures that can close all security holes except social engineering attacks (and even those can be minimized). As they say, "Absence of evidence, is not evidence of absence", so do not assume that they don't exist simply because you've never heard of them.
You can start on my prior post in this discussion, and look up typed assembly languages, proof-carrying code, managed code, virtual machines, virtualization, capability security, types systems, and so on. I think that's a good starting point on various approaches to safety and security at various levels of abstraction from high-level languages to low-level assembly code.
99% of security is bandaid and "obscurity" under cover. Even cryptography with large prime numbers is just obscurity: they give you the number and if you could factor is quickly, you can break it. You just can't break it quickly yet.
The difference is that crypto has well-known mathematical properties that you can rely on. Other obscure security measures do not have properties you can rely on, have not been studied rigourously and so you are relying on a foundation of unexamined assumptions and guesswork. There is a significant difference between the strength of the two, and I'll trust my secrets to security by mathematically rigourous obscurity, but not to security by unrigourous obscurity.
Microsoft definitely has something going on with.NET code though. The kind of security you can get there can't be compared with anything you can do on the software or even hardware level, with pure unmanaged code.
Of course, both of these statements are wrong. Lisp machines had finer grained authority management, as did earlier capability hardware (tagging down to the word level); we're talking technology from the 70s and 80s here which can surpass the capabilities of new millennium technology.
Typed Assembly Languages are "unmanaged code", ie. raw assembly, but are accompanied with a proof certificate proving various properties of the assembly code, including memory safety and beyond. This is more recent work under the banner of "proof carrying code". This counts as a software technique which is superior to.NET's managed code. Heck,.NET's managed code can't even express strongly typed function pointers, and must resort to ad-hoc delegate techniques in the VM (despite many researchers suggesting MS add them way back in the early design stages of.NET).
I like.NET to a certain extent, and I like Microsoft's Singularity project, but.NET is far from the true cutting edge in safety. Unfortunately, Java is no better off, and functional languages are only marginally better when it comes to security.
Although frankly, I'm not sure a JavaScript attack of the type in the GP (GGP? I lost count) is possible. Browsers have some pretty strict limits on cross-site scripting. But better safe than sorry.
Such an attack is quite trivial, and does not depend on cross-site scripting. The intercepted JS file simply needs to change the target of the form submission for every form on the page.
There's a lot more out there and the consensus is that basically, a very small percentage of people host a majority of the content and that "free-riding" is more of a threat to P2P networks than litigation.
Neither of those studies correlates free-riding with greed, nor did you point to a study of records execs that correlates their actions with greed. In fact, no motives at all are ascribed to free-riders; the minority of hosts that share the majority of files might very well be technically adept people with computers that run 24/7, while the free-riders are simply home users behinds NAT firewalls who shut off their computers as soon as their downloads are finished because they just don't know any better; there's no way to know. Unless you can point to a more definitive study, your original statements are still suppositions.
A better idea would be to simply copy the js file to your local server; that way, clients would load the file over the https connection they already established to your server, and your page won't break if Google Analytics upgrade the contents of the file.
No they're not -- I mean, I admire the spirit you're trying to paint them in and all, but no, they're (for the most part) just greedy people, just like the record execs, trying to get more for less, even if it's not legal.
Run a poll of file sharers or record execs have you? Performed a psychological study perhaps? No? I find it interesting how quick people are to judge the motives of others from their actions. How about we keep pop psych judgments out of the arguments, and stick to the facts of the justifiability of copyright, the penalties for copyright infringement, the viability of music distribution given the spread of the internet, etc. At least then we'd be debating the facts on important issues instead of suppositions.
the Supreme Court of California have held that Jury Nullification is "contrary to [the court's] ideal of justice of equal justice for all and permits both the prosecution's case and the defendant's fate to depend upon the whims of a particular jury, rather than upon the equal application of settled rules of law."
I think the important question implied by the above: these rules of law are settled by whom? Congressmen? Judges? I think "the people" is ultimately the only justifiable answer.
For those companies that use Urchin, note that there is a potential security vulnerability that I came across on a copmany's ordering page just a few days ago. The company, who shall remain nameless, has since taken my suggestion and closed the security hole, but I don't know how many more ordering screens use Urchin in the same way.
The problem is thus:
1. The ordering screen where you enter your VISA card number is loaded over https 2. The ordering screen includes the urchin.js script file, but this file is loaded over unsecured http 3. This means that urchin.js could be replaced in transit with another script which could steal your personal info by, for instance, changing the form you are submitting to point to another server.
In this case, the Firefox "lock" icon displays an error: "Warning: Contains unauthenticated content". Unfortunately, this is very easy to miss. I only spotted it because I use the Petname Toolbar, which prevents phishing and spoofing. The toolbar would not let me set a petname for this site, because the unsecured content could literally change anything on the page, so it wasn't safe. If you don't already have the Petname Toolbar installed, I highly recommend that you install it.
Urchin could close this hole if they allowed urchin.js to be loaded over https, but the file isn't available over a secured link. To anyone using urchin.js, make sure you don't include that file on your secured pages.
What's even more disheartening, is that this site was verified as "hacker safe" by ScanAlert; missing such an obvious hole really decreases my confidence in their testing methods.
Even the OS eventually terminates. I'd still put forth my paradigm works.
An OS, as mathematical function, is a recursive, non-terminating program. It MAY terminate, but it need not.
Accounting is a part of management. However, management goes further in that it assumes responsibility for allocating and de-allocating resources.
Accounting is not done in any mainstream language in any usable manner. Regardless, I've been arguing the lifecycle of objects is better managed automatically than manually, and you have been arguing that, at least sometimes but likely often, lifecycle needs to be managed manually. The majority of security bugs found today would have been avoided if the software had been written in a memory-safe language, and many memory leaks would not exist given AMM. We can argue the performance tradeoffs of memory safety and AMM (empirical evidence suggest exec overheads around 15-20% and memory overheads around 50-100%), but that they both eliminate large classes of bugs, including security vulnerabilities, is an indisputable fact.
However, the programmer still should have a way to tell it when it is done - perhaps as the programmer I want to release memory half way through a function instead of waiting for the pointer to go out of scope when the function exits.
But why? If the region-inferencer (for example), determines that the lifecycle of a chunk of memory isn't used halfway through the function, then it will do it for you. If it's not smart enough, then you can refactor your function into two functions to ensure that regions are scoped differently. As a bonus, this results in a better design.
Further, your approach can have a pathological effect on performance due to micromanagement. Why incur all the overhead of alloc/free'ing individual objects when you can alloc/free entire regions of objects at once. This is incredibly efficient, and further, leads to more efficient bump-pointer allocation techniques. Are you aware of the searching and fragmentation overhead induced by libc's malloc/free? This has been extensively studied.
We know how to write software that is only as secure as the attack vectors that we are aware of. Claiming otherwise is foolishness.
I can legitimately claim otherwise because software written to a POLA standard is maximally defensive, and so any remaining security holes are either a) an implementation bug which does not follow the specification, or b) inherent to the problem being solved and thus, fundamentally unsolvable without changing the problem specification.
Stronger static types systems help reduce a) (and C/C++ have very weak type systems), and b) is essentially unsolvable without manual intervention.
We can mitigate how software is affected by unknown attack vectors through Defensive Programming methodology, but even that can only truly protect against known vectors.
Like most generalities, your statement is both true and false. It is false in the sense that a POLA design is already maximally defensive, and so the security properties can't be made any stronger without changing the entire specification.
It's true because of the human factor in any system, and what you'll quickly find is that the majority of the security research by the capability security community are human-computer interaction attacks, ie. phishing, spoofing, etc. This is because automated attack vectors are no longer viable in POLA systems. I suggest you read the security audit of the DarpaBrowser built on the capability-secure language E for a taste.
The "Defensive Programming Methodology" is actually a degenerate, specialized case of capability security.
Additionally, reliance on a "memory-safe" language does not absolve you from buffer overflow attacks. Such reliance is foolishness - and is no better than security through obscur
There is no inherent right to enter to a place of public performance and make an unauthorized recording, and *IT SAYS SO ON THE BACK OF YOUR TICKET*.
If it's a public place, then I do have the right to record anything happening there, as long as I don't focus exclusively on a single subject without their permission (privacy laws). Movie theatres are not public places, they are private property, and THIS is why they can enforce the "no camcorders" rule; I don't see how this law is any more effective in achieving that.
Also, the fact that it is an "unauthorized recording" is already assuming a notion of copyright, which is not a natural "god-given" right.
I propose that that is really the symptom of a memory leak, and that a memory leak is truly maintaining memory beyond when it is needed. This is something a GC cannot solve, as you may still have a valid pointer pointing to the memory still in scope even when the memory is no longer needed.
How does this differ? Consider a single function that allocates some memory, makes use of it, and then goes on to do something else that doesn't require the memory; the pointer to the memory is in scope throughout the entire life of the function.
Let's define two terms to further clarify: automatic memory management (AMM) and manual memory management (MMM). Given a particular AMM, your statement might be true. However, it is not true for all AMM techniques. It is also not true of all MMM techniques, but this property depends on the cleverness of the end-programmer, instead of the compiler implementor. I think you'll agree that the compiler implementor is likely to be the better programmer.
Honestly, OS's have to manage their resources - file systems, memory, processor time, and all kinds of stuff - and in reality, every program is in effect a small operating system dedicated to a single task, the task of what the program is trying to achieve, that is built on top of other operating systems - e.g. standing on the shoulders of giants.
The set of all programs that are non-terminating (like an OS) is a subset of the set of all programs. So no, not every program is like an OS. It also does not follow that a program must manage every byte of memory, because OS's deal with resources at a coarser granularity (pages mostly).
Programs really do need to manage their resources
I do not contest the statement that resources must be properly accounted for in any system (as improper accounting is the source of many security vulnerabilities), but I do contest the statement that this accounting must be manual.
GC's allow a programmer to be lazy by not doing this; languages like C and C++ - Pascal, Ada, and many others even - force programmers to manage their memory or risk crashing due to memory leaks (" normal" definition memory leaks).
It's not a matter of laziness, it's a matter of hard design and error-prone usage. Introducing MMM has a ripple effect on an entire system, where its structure becomes exponentially more complicated in order to properly manage resources crossing interface boundaries. You can see this for yourself by contrasting the simplicity of libraries written in functional languages against those written in C/C++.
It is only impossible to entirely eliminate it if the lower levels don't manage their memory properly either.
This implies a stack-based memory hierarchy, in which case automatic region-inference could allocate and deallocate this memory for you even more efficiently than you yourself could. That's a solved problem. Problem is, resource lifecycles are often not stack-based; fortunately, newer region inference techniques are getting good at tackling these issues as well, and I predict that within 5 years we'll have an acceptable automatic region inference technique that will outperform MMM.
however, my code managed its memory properly and that was the only memory issue in the entire program. If Microsoft did their job, then they would have managed their memory and the memory leak would not be there at all.
Or, in order to close that 4 byte leak, MS would have had to alter the API in such a way that would force YOUR program to leak, or force you to contort your program and stand on your head in order to ensure leak-freedom. Fact is, we should leave the problems that are amenable to automation to the computers, and those that are not amenable to automation to the programmers. Memory management is an example of the former, and while there are currently domains where the automated solutions are not yet good enough, that gap is almost closed.
Your arguments go to the sink the moment that I allocate 90% of my objects in the stack.
I don't use new if I don't need it.
If your allocation patterns follow purely stack semantics, then region-based memory management is as efficient as you can get. It's more efficient than stack-allocating values since it minimizes the copying inherent to C/C++ value semantics.
A well-written C++ program is going to free memory much faster than a GC can. The value of GC is that you don't have to worry about forgetting to free memory, it will happen - eventually.
Vague and unsubstantiated statement. This is not a question of C++ vs. GC, this is a question of manual memory management algorithms (MMM) vs. automatic memory management algorithms (AMM), and what is a better fit given your application's resource usage patterns. For instance, the libc MMM produces fragmentation, whereas a compacting GC yields higher locality, so if your application induces a great deal of fragmentation and benefits greatly from higher locality, then GC will likely be more optimal.
Further, there are other AMM algorithms besides GC (see region-based memory management) which approach the efficiency of customized, arena-based MMM, which is as efficient as you can get; the "unsolved" problem is automatically inferring where regions should be allocated and freed based on the source code; workable solutions to this problem have been recently published, so the next few years look to be very interesting indeed.
Actually, the big language culprits would be those with auto-garbage collection, etc. as they tend to have lazier programmers that don't "need" to manage their own resources, and in some cases even prohibit the programmer from being able to manage their resources.
Given this comment, I'm pretty sure the only garbage collected language you've used is Java, or perhaps a community language like Python. I assure you that garbage collection is quite efficient in serious languages when compared to manual memory management (see OCaml) if you actually read the GC literature on effective algorithms and not simply assume reference counting or other naive GC scheme is clearly optimal; more importantly, automatic memory management is much safer since there are no leaks.
Heck, even Mono's C# implementation uses half the memory of the Java VM, and Mono still uses conservative GC, not accurate GC! Memory efficient GC'd languages are possible, and profiling your application in such languages to isolate and optimize resource use is entirely possible, and in the end, you have no leaks due to the automatic memory management. You can't say the latter for any C/C++ software.
C/C++ and similar languages, on the other hand, force the programmers to manage their resources.
This what I call "The Grand Misconception". C/C++ does not "force" you to manage resources at all. In fact, the complete lack of this forcing is the result of most bugs with C/C++ programs: leaks, buffer overflows, etc. The C/C++ type systems are simply not powerful enough to reason about resource lifecycles, which means you are free to manage resources, or not, or manage them improperly, at your leisure; sounds great sometimes, and yet it leaves us with software like IE, Firefox, etc., which are generally funtional, but where leaks and security holes are prevalent and likely impossible to entirely eliminate. Any resource leak is an exploitable security hole, period (but not the only source of security holes).
If a language did actually force you to manage resources, then it would produce compile-time errors when you misused a resource, ie. early deallocation, dangling pointers, etc. If you don't understand what that means, then I suggest you read up on more CS literature, specifically linear types, alias types, region types, and region-based memory management (as used in the Cyclone language). These are type systems where resources can be managed more explicitly, but which produce compile-time errors when a resource is misused in some way.
I'm not sure what your point is, other than to further illustrate that idealised communism isn't realistic, a fact I've already admitted.
My point was that socialism, not capitalism, requires perfect information, which contradicts your original statement.
Also, a slight correction to my original post where I made a nomenclature error: I intended to refer to common goods, not public goods as requiring controls.
BS. Take, for example, drugs. In a pure capitalist world, a company is free to market drugs with long-term side-effects. In this case, you have a combination of asymmetric information (the drug company is aware but chooses not to share the information), combined with externalities (long-term health costs). I'm sure one could come up with many other examples (the insurance industry comes to mind).
Most free market/capitalist enthusiasts agree on one thing besides removing unnecessary market controls: fraud must be outlawed. A pharma company claiming that a drug is a miracle cure and does not list known side effects, is implicitly stating that there are no side-effects.
Let's instead consider the situation where the pharma company does not even perform the research into the side-effects beyond the basic research and testing required to verify that it does in fact treat the condition (due to anti-fraud, they must at least do this). Assuming disclosure of the very limited testing due to anti-fraud, would you as a consumer take this drug when compared to a drug which has undergone rigourous testing but costs 3 times as much? Not when it's first pushed out perhaps, but after 10,000 poorer/cheaper people have taken it, and the side-effects are more well-known, perhaps you will.
What about those poor people? Well, when faced with the possibility of suffering with their condition with no treatment, or treating the condition with unknown side-effects, they have a choice; sure it's a sucky choice, but given the cost of pharmaceuticals now, they may not even be able to afford treatment today at all. Cheaper but untested drugs are arguably providing them a new choice not available today, while not necessarily compromising *your* choice to stick with safer drugs.
Now we must question an assumption: why control for fraud and force disclosure of known information? Arguably, this goes part way to your "perfect information", but not nearly all the way. Information about products is itself a good, and in fact it is a public good: a good that may not be sufficiently produced in free markets if left to its own devices (although publications like Consumer Reports have made a good show of making a private good out of information). We can legally mandate the production of this good effecting a market control (as we do now via FDA, etc.), or we can distribute the onus for testing on those willing to volunteer because they have an vested interest in it. I haven't studied the problem in sufficient depth to determine which is a more viable option, but I suspect that we are currently more regulated than we need to be here.
Ultimately, as I suspect you're aware, all common goods require some control mechanism to mediate access and prevent abuse, and a few public goods may require a mandatory third party supported by all citizens; this control does not necessarily imply that a single monopoly must regulate all public goods (the government), simply that each common good be controlled by some mechanism (food and drugs by the FDA, the environment by an environmental organization, the use of legal force by the judicial system, or some such distribution of powers) and that these various controls need not be subject to a single mandate.
No, capitalism is poor in any case where there are negative externalities. These externalities aren't factored into the cost of products, and thus are effectively subsidized. This can be true of both pub
And pure capitalism (the analog of communism) requires, among other things, perfect information, thus relying on humans who don't lie, cheat, or steal.
On the contrary, socialism requires perfect information in order to perfectly plan and allocate resources. Capitalism and free markets have hidden/implicit information which is transmitted via the price of goods; a manufacturer doesn't need to know why the price of steel went up, just whether it is now worth switching to aluminium.
Capitalism requires perfect information only if you want or need to make a perfect long-term decision every time; this is rarely necessary, but when it is important, the onus is on the person who values the good so highly. I have a hard time seeing why such a distributed, fault tolerant system is a bad thing.
Capitalism and free markets are poor at dealing with public goods (such as the environment), but public goods are the only contingency that needs special handling; the important question is: how many and which goods are public goods?
capitalism runs off of capital, which is excess value created by work that laborers have done (profit). So inherently, capitalism takes advantage of those people who are forced (or choose) to sell their labor for less than the value of what they produce.
Which is predicated on the assumption that value is an absolute, not a relative measure. Unfortunately, this assumption is clearly false, and this is why anti-capitalists towing the "exploitation" line are full of it.
I think you seriously overestimate MS, or any company for that matter. Disregarding the, IMO, ludicrous notion that MS even has enough money to buy all the ISPs, all the power companies, and all the cable companies in the entire world, the bureaucratic overhead of running such a monstrous organization already makes it non-competitive with smaller companies.
Trivially... With a more powerful transmitter to jam such radio signals. No FCC to stop them, right?
True, assuming an extremist libertarian position, then the FCC wouldn't exist. But do you honestly believe that MS, or insert other future monopoly, will set up radio transmitters in every locale of interest, and pay to run them 24/7 to ensure their dominance as an ISP? Do you have any idea how much money it would cost to power those transmissions so they cover a sufficiently large area? The power required is honestly obscene, and I think you'd be hard-pressed to prove that the profits made by being the only ISP outweigh cost of running the jammers.
Furthermore, such warfare tactics induce serious ill-will and would ensure that alternatives come hard and fast. Finally, radio is not the only transmission medium; there is satellite, line of sight optical networks, and wide-spectrum radio systems. Developing and running a wide-spectrum jammer is even more expensive than narrow-band jammers; this monopoly would be fighting a never-ending guerilla war that they have no hope of ever winning.
As a child, it is highly unlikely you have done anything worthwhile. There is simply no reason why any responsible adult should give you (as a child) any "respect" at all.
Adults are no more deserving of respect than children. I know some children I respect more than some adults in fact. Any relationship between two parties has its own dynamic, but it's a dynamic that develops naturally through extended interaction between said parties; like trust, respect is earned, though there is a irreducible level of respect that every human being deserves. That goes for adults and children alike.
Witness the fact that Microsoft became large and powerful precisely *because* it abused its position, and its position still gives it huge amounts of leverage against encroachment by these open standards.
Doubtful. At the time, DOS was one of the only extremely cheap OSs that took personal computing seriously, in particular for business use; most everyone else was still focused on mainframes for business. If anything, MS demonstrated the power of first-mover advantage, because by the time IBM and Compaq recognized their error, MS was the business platform.
I agree that MS used predatory practices to maintain their stranglehold, but that's a whole separate issue which I already argued has been adequately tackled by open source.
I think that--in a Libertarian world--far more companies would maintain their profitability by abusing the system than would lose their profitability through such abuse.
I'm not sure it can be legitimately labeled "abuse", and particularly not in a libertarian world. MS and OEMs have a supplier/customer relationship, and if MS wants to make demands of their customers, they're within their rights to do so. OEMs will lose profitability only when MS' demands become so onerous as to cost OEMs more than they could make by selling MS software; otherwise, OEMs are still profiting from their agreement with MS, and it's up to them to decide whether the margin is too slim too warrant acquiescing to MS. Before Linux's push to the desktop there were few serious alternatives, and that need caused people to create one. And it's working: this threat is causing MS to re-evaluate their position, and has produced a legitimate alternative platform. Problem solved.
In conclusion, it's irrelevant if more companies will be profitable due to "predatory practices" than would lose money; the real question is whether the situation is self-correcting, and I've made a legitimate argument that it is. I haven't heard a strong argument why monopolies require government intervention because they are not self-correcting.
There is obscene amounts of evidence that the opposite is true. The more they abuse their position, the more they can assure no competition can possibly spring up.
I'd be interested to read about this evidence. Monopolies are generally toppled by competition, either from outside of their market (such as aluminium competing with the old steel monopolies), or from within their market once their abuse goes too far; in the software world, the obstacle of Microsoft seemed insurmountable, such that no one could ever envision being price competitive. Thus, a grassroots volunteer effort ended up challenging them, since even Microsoft could never hope to beat a $0 price point.
So I'd say there's also abundant evidence that regardless of how entrenched a monopoly may seem, they'll only last as long as they are providing value to someone above and beyond their competition. In that case, where is the need for regulation?
Just wait until Microsoft buys your ISP, which then bans users from visiting web sites hosting open source code.
Then Google, which has already been buying fibre across the continent and which depends on open source software, will offer an alternative. Does MS have enough money to purchase all the power companies when they start offering broadband over powerlines too? Are they going to buy the cable and the telecom companies? How can they stop a grassroots, community wireless ISP? Does MS really have the resources to buy every ISP on the planet?
I think it's a very narrow and pessimistic view that monopolies can only be controlled and overthrown by another monopoly, in this case, the government.
Slashdot Mirror
If it was so easy as you suggest then it would be in use right now. However, it's not.
That it's not, is obvious by observation. That it can be easy, is possible given the right "tools". That even if it were easy implies we would be using it, simply does not follow. There are many factors influencing popularity, and as we all know, "the best" does not always win.
It's not that it is impossible to write 100% perfect software but it might as well be due to the limitations of humans.
It is undoubtedly due to the limitations of humans. Our limitations is the entire point of abstraction, and why it's such a powerful organizing principle for humans: it reduces the complexity of a system to a well-defined, locally causal set of interactions (the interface). The more powerful the abstraction, the more likely the software constructed from it is correct.
This is why strong type systems, functional programming idioms, algebraic data types, modules, etc. yield software that is very close to "correct by construction": they are powerful abstraction mechanisms that are understandable by humans, yet still reasonably efficient. Unfortunately, they are not as popular, and not for any technical deficiency (though that may have been true at some point), but mostly by inertia.
If a god existed, and its creation did have a purpose, why disguise the purpose? Why not have it explicitly available to all sentient beings?
Come on, the answer to this is trivial. For all we know, we're simply an anthropological experiment or simulation by some advanced civilization, whose express purpose is to see how long it takes us to figure that fact out.
However, the physical evidence is there, and many of us belive God does not lie in either nature or in scripture.
Then the other question you have to ask yourself is, "what makes scripture the word of God?" Ultimately, the only answer is faith, and if you choose to believe something with no evidence, I don't see how you can ever hope to reconcile this with a philosophy that requires evidence before belief. All you end up doing is fitting facts to your interpretation.
There is just no way to do this in software.
As a famous physicist once said, "You're not even wrong". There are plenty of software architectures that can close all security holes except social engineering attacks (and even those can be minimized). As they say, "Absence of evidence, is not evidence of absence", so do not assume that they don't exist simply because you've never heard of them.
You can start on my prior post in this discussion, and look up typed assembly languages, proof-carrying code, managed code, virtual machines, virtualization, capability security, types systems, and so on. I think that's a good starting point on various approaches to safety and security at various levels of abstraction from high-level languages to low-level assembly code.
99% of security is bandaid and "obscurity" under cover. Even cryptography with large prime numbers is just obscurity: they give you the number and if you could factor is quickly, you can break it. You just can't break it quickly yet.
The difference is that crypto has well-known mathematical properties that you can rely on. Other obscure security measures do not have properties you can rely on, have not been studied rigourously and so you are relying on a foundation of unexamined assumptions and guesswork. There is a significant difference between the strength of the two, and I'll trust my secrets to security by mathematically rigourous obscurity, but not to security by unrigourous obscurity.
Microsoft definitely has something going on with .NET code though. The kind of security you can get there can't be compared with anything you can do on the software or even hardware level, with pure unmanaged code.
.NET's managed code. Heck, .NET's managed code can't even express strongly typed function pointers, and must resort to ad-hoc delegate techniques in the VM (despite many researchers suggesting MS add them way back in the early design stages of .NET).
.NET to a certain extent, and I like Microsoft's Singularity project, but .NET is far from the true cutting edge in safety. Unfortunately, Java is no better off, and functional languages are only marginally better when it comes to security.
Of course, both of these statements are wrong. Lisp machines had finer grained authority management, as did earlier capability hardware (tagging down to the word level); we're talking technology from the 70s and 80s here which can surpass the capabilities of new millennium technology.
Typed Assembly Languages are "unmanaged code", ie. raw assembly, but are accompanied with a proof certificate proving various properties of the assembly code, including memory safety and beyond. This is more recent work under the banner of "proof carrying code". This counts as a software technique which is superior to
I like
Although frankly, I'm not sure a JavaScript attack of the type in the GP (GGP? I lost count) is possible. Browsers have some pretty strict limits on cross-site scripting. But better safe than sorry.
Such an attack is quite trivial, and does not depend on cross-site scripting. The intercepted JS file simply needs to change the target of the form submission for every form on the page.
There's a lot more out there and the consensus is that basically, a very small percentage of people host a majority of the content and that "free-riding" is more of a threat to P2P networks than litigation.
Neither of those studies correlates free-riding with greed, nor did you point to a study of records execs that correlates their actions with greed. In fact, no motives at all are ascribed to free-riders; the minority of hosts that share the majority of files might very well be technically adept people with computers that run 24/7, while the free-riders are simply home users behinds NAT firewalls who shut off their computers as soon as their downloads are finished because they just don't know any better; there's no way to know. Unless you can point to a more definitive study, your original statements are still suppositions.
Excellent! To anyone else still browsing, the urchin.js is available over https after all. Thanks AC!
A better idea would be to simply copy the js file to your local server; that way, clients would load the file over the https connection they already established to your server, and your page won't break if Google Analytics upgrade the contents of the file.
No they're not -- I mean, I admire the spirit you're trying to paint them in and all, but no, they're (for the most part) just greedy people, just like the record execs, trying to get more for less, even if it's not legal.
Run a poll of file sharers or record execs have you? Performed a psychological study perhaps? No? I find it interesting how quick people are to judge the motives of others from their actions. How about we keep pop psych judgments out of the arguments, and stick to the facts of the justifiability of copyright, the penalties for copyright infringement, the viability of music distribution given the spread of the internet, etc. At least then we'd be debating the facts on important issues instead of suppositions.
the Supreme Court of California have held that Jury Nullification is "contrary to [the court's] ideal of justice of equal justice for all and permits both the prosecution's case and the defendant's fate to depend upon the whims of a particular jury, rather than upon the equal application of settled rules of law."
I think the important question implied by the above: these rules of law are settled by whom? Congressmen? Judges? I think "the people" is ultimately the only justifiable answer.
For those companies that use Urchin, note that there is a potential security vulnerability that I came across on a copmany's ordering page just a few days ago. The company, who shall remain nameless, has since taken my suggestion and closed the security hole, but I don't know how many more ordering screens use Urchin in the same way.
The problem is thus:
1. The ordering screen where you enter your VISA card number is loaded over https
2. The ordering screen includes the urchin.js script file, but this file is loaded over unsecured http
3. This means that urchin.js could be replaced in transit with another script which could steal your personal info by, for instance, changing the form you are submitting to point to another server.
In this case, the Firefox "lock" icon displays an error: "Warning: Contains unauthenticated content". Unfortunately, this is very easy to miss. I only spotted it because I use the Petname Toolbar, which prevents phishing and spoofing. The toolbar would not let me set a petname for this site, because the unsecured content could literally change anything on the page, so it wasn't safe. If you don't already have the Petname Toolbar installed, I highly recommend that you install it.
Urchin could close this hole if they allowed urchin.js to be loaded over https, but the file isn't available over a secured link. To anyone using urchin.js, make sure you don't include that file on your secured pages.
What's even more disheartening, is that this site was verified as "hacker safe" by ScanAlert; missing such an obvious hole really decreases my confidence in their testing methods.
Even the OS eventually terminates. I'd still put forth my paradigm works.
An OS, as mathematical function, is a recursive, non-terminating program. It MAY terminate, but it need not.
Accounting is a part of management. However, management goes further in that it assumes responsibility for allocating and de-allocating resources.
Accounting is not done in any mainstream language in any usable manner. Regardless, I've been arguing the lifecycle of objects is better managed automatically than manually, and you have been arguing that, at least sometimes but likely often, lifecycle needs to be managed manually. The majority of security bugs found today would have been avoided if the software had been written in a memory-safe language, and many memory leaks would not exist given AMM. We can argue the performance tradeoffs of memory safety and AMM (empirical evidence suggest exec overheads around 15-20% and memory overheads around 50-100%), but that they both eliminate large classes of bugs, including security vulnerabilities, is an indisputable fact.
However, the programmer still should have a way to tell it when it is done - perhaps as the programmer I want to release memory half way through a function instead of waiting for the pointer to go out of scope when the function exits.
But why? If the region-inferencer (for example), determines that the lifecycle of a chunk of memory isn't used halfway through the function, then it will do it for you. If it's not smart enough, then you can refactor your function into two functions to ensure that regions are scoped differently. As a bonus, this results in a better design.
Further, your approach can have a pathological effect on performance due to micromanagement. Why incur all the overhead of alloc/free'ing individual objects when you can alloc/free entire regions of objects at once. This is incredibly efficient, and further, leads to more efficient bump-pointer allocation techniques. Are you aware of the searching and fragmentation overhead induced by libc's malloc/free? This has been extensively studied.
We know how to write software that is only as secure as the attack vectors that we are aware of. Claiming otherwise is foolishness.
I can legitimately claim otherwise because software written to a POLA standard is maximally defensive, and so any remaining security holes are either
a) an implementation bug which does not follow the specification, or
b) inherent to the problem being solved and thus, fundamentally unsolvable without changing the problem specification.
Stronger static types systems help reduce a) (and C/C++ have very weak type systems), and b) is essentially unsolvable without manual intervention.
We can mitigate how software is affected by unknown attack vectors through Defensive Programming methodology, but even that can only truly protect against known vectors.
Like most generalities, your statement is both true and false. It is false in the sense that a POLA design is already maximally defensive, and so the security properties can't be made any stronger without changing the entire specification.
It's true because of the human factor in any system, and what you'll quickly find is that the majority of the security research by the capability security community are human-computer interaction attacks, ie. phishing, spoofing, etc. This is because automated attack vectors are no longer viable in POLA systems. I suggest you read the security audit of the DarpaBrowser built on the capability-secure language E for a taste.
The "Defensive Programming Methodology" is actually a degenerate, specialized case of capability security.
Additionally, reliance on a "memory-safe" language does not absolve you from buffer overflow attacks. Such reliance is foolishness - and is no better than security through obscur
There is no inherent right to enter to a place of public performance and make an unauthorized recording, and *IT SAYS SO ON THE BACK OF YOUR TICKET*.
If it's a public place, then I do have the right to record anything happening there, as long as I don't focus exclusively on a single subject without their permission (privacy laws). Movie theatres are not public places, they are private property, and THIS is why they can enforce the "no camcorders" rule; I don't see how this law is any more effective in achieving that.
Also, the fact that it is an "unauthorized recording" is already assuming a notion of copyright, which is not a natural "god-given" right.
I propose that that is really the symptom of a memory leak, and that a memory leak is truly maintaining memory beyond when it is needed. This is something a GC cannot solve, as you may still have a valid pointer pointing to the memory still in scope even when the memory is no longer needed.
How does this differ? Consider a single function that allocates some memory, makes use of it, and then goes on to do something else that doesn't require the memory; the pointer to the memory is in scope throughout the entire life of the function.
Let's define two terms to further clarify: automatic memory management (AMM) and manual memory management (MMM). Given a particular AMM, your statement might be true. However, it is not true for all AMM techniques. It is also not true of all MMM techniques, but this property depends on the cleverness of the end-programmer, instead of the compiler implementor. I think you'll agree that the compiler implementor is likely to be the better programmer.
Honestly, OS's have to manage their resources - file systems, memory, processor time, and all kinds of stuff - and in reality, every program is in effect a small operating system dedicated to a single task, the task of what the program is trying to achieve, that is built on top of other operating systems - e.g. standing on the shoulders of giants.
The set of all programs that are non-terminating (like an OS) is a subset of the set of all programs. So no, not every program is like an OS. It also does not follow that a program must manage every byte of memory, because OS's deal with resources at a coarser granularity (pages mostly).
Programs really do need to manage their resources
I do not contest the statement that resources must be properly accounted for in any system (as improper accounting is the source of many security vulnerabilities), but I do contest the statement that this accounting must be manual.
GC's allow a programmer to be lazy by not doing this; languages like C and C++ - Pascal, Ada, and many others even - force programmers to manage their memory or risk crashing due to memory leaks (" normal" definition memory leaks).
It's not a matter of laziness, it's a matter of hard design and error-prone usage. Introducing MMM has a ripple effect on an entire system, where its structure becomes exponentially more complicated in order to properly manage resources crossing interface boundaries. You can see this for yourself by contrasting the simplicity of libraries written in functional languages against those written in C/C++.
It is only impossible to entirely eliminate it if the lower levels don't manage their memory properly either.
This implies a stack-based memory hierarchy, in which case automatic region-inference could allocate and deallocate this memory for you even more efficiently than you yourself could. That's a solved problem. Problem is, resource lifecycles are often not stack-based; fortunately, newer region inference techniques are getting good at tackling these issues as well, and I predict that within 5 years we'll have an acceptable automatic region inference technique that will outperform MMM.
however, my code managed its memory properly and that was the only memory issue in the entire program. If Microsoft did their job, then they would have managed their memory and the memory leak would not be there at all.
Or, in order to close that 4 byte leak, MS would have had to alter the API in such a way that would force YOUR program to leak, or force you to contort your program and stand on your head in order to ensure leak-freedom. Fact is, we should leave the problems that are amenable to automation to the computers, and those that are not amenable to automation to the programmers. Memory management is an example of the former, and while there are currently domains where the automated solutions are not yet good enough, that gap is almost closed.
I will grant you that security hol
Your arguments go to the sink the moment that I allocate 90% of my objects in the stack.
I don't use new if I don't need it.
If your allocation patterns follow purely stack semantics, then region-based memory management is as efficient as you can get. It's more efficient than stack-allocating values since it minimizes the copying inherent to C/C++ value semantics.
A well-written C++ program is going to free memory much faster than a GC can. The value of GC is that you don't have to worry about forgetting to free memory, it will happen - eventually.
Vague and unsubstantiated statement. This is not a question of C++ vs. GC, this is a question of manual memory management algorithms (MMM) vs. automatic memory management algorithms (AMM), and what is a better fit given your application's resource usage patterns. For instance, the libc MMM produces fragmentation, whereas a compacting GC yields higher locality, so if your application induces a great deal of fragmentation and benefits greatly from higher locality, then GC will likely be more optimal.
Further, there are other AMM algorithms besides GC (see region-based memory management) which approach the efficiency of customized, arena-based MMM, which is as efficient as you can get; the "unsolved" problem is automatically inferring where regions should be allocated and freed based on the source code; workable solutions to this problem have been recently published, so the next few years look to be very interesting indeed.
Actually, the big language culprits would be those with auto-garbage collection, etc. as they tend to have lazier programmers that don't "need" to manage their own resources, and in some cases even prohibit the programmer from being able to manage their resources.
Given this comment, I'm pretty sure the only garbage collected language you've used is Java, or perhaps a community language like Python. I assure you that garbage collection is quite efficient in serious languages when compared to manual memory management (see OCaml) if you actually read the GC literature on effective algorithms and not simply assume reference counting or other naive GC scheme is clearly optimal; more importantly, automatic memory management is much safer since there are no leaks.
Heck, even Mono's C# implementation uses half the memory of the Java VM, and Mono still uses conservative GC, not accurate GC! Memory efficient GC'd languages are possible, and profiling your application in such languages to isolate and optimize resource use is entirely possible, and in the end, you have no leaks due to the automatic memory management. You can't say the latter for any C/C++ software.
C/C++ and similar languages, on the other hand, force the programmers to manage their resources.
This what I call "The Grand Misconception". C/C++ does not "force" you to manage resources at all. In fact, the complete lack of this forcing is the result of most bugs with C/C++ programs: leaks, buffer overflows, etc. The C/C++ type systems are simply not powerful enough to reason about resource lifecycles, which means you are free to manage resources, or not, or manage them improperly, at your leisure; sounds great sometimes, and yet it leaves us with software like IE, Firefox, etc., which are generally funtional, but where leaks and security holes are prevalent and likely impossible to entirely eliminate. Any resource leak is an exploitable security hole, period (but not the only source of security holes).
If a language did actually force you to manage resources, then it would produce compile-time errors when you misused a resource, ie. early deallocation, dangling pointers, etc. If you don't understand what that means, then I suggest you read up on more CS literature, specifically linear types, alias types, region types, and region-based memory management (as used in the Cyclone language). These are type systems where resources can be managed more explicitly, but which produce compile-time errors when a resource is misused in some way.
I'm not sure what your point is, other than to further illustrate that idealised communism isn't realistic, a fact I've already admitted.
My point was that socialism, not capitalism, requires perfect information, which contradicts your original statement.
Also, a slight correction to my original post where I made a nomenclature error: I intended to refer to common goods, not public goods as requiring controls.
BS. Take, for example, drugs. In a pure capitalist world, a company is free to market drugs with long-term side-effects. In this case, you have a combination of asymmetric information (the drug company is aware but chooses not to share the information), combined with externalities (long-term health costs). I'm sure one could come up with many other examples (the insurance industry comes to mind).
Most free market/capitalist enthusiasts agree on one thing besides removing unnecessary market controls: fraud must be outlawed. A pharma company claiming that a drug is a miracle cure and does not list known side effects, is implicitly stating that there are no side-effects.
Let's instead consider the situation where the pharma company does not even perform the research into the side-effects beyond the basic research and testing required to verify that it does in fact treat the condition (due to anti-fraud, they must at least do this). Assuming disclosure of the very limited testing due to anti-fraud, would you as a consumer take this drug when compared to a drug which has undergone rigourous testing but costs 3 times as much? Not when it's first pushed out perhaps, but after 10,000 poorer/cheaper people have taken it, and the side-effects are more well-known, perhaps you will.
What about those poor people? Well, when faced with the possibility of suffering with their condition with no treatment, or treating the condition with unknown side-effects, they have a choice; sure it's a sucky choice, but given the cost of pharmaceuticals now, they may not even be able to afford treatment today at all. Cheaper but untested drugs are arguably providing them a new choice not available today, while not necessarily compromising *your* choice to stick with safer drugs.
Now we must question an assumption: why control for fraud and force disclosure of known information? Arguably, this goes part way to your "perfect information", but not nearly all the way. Information about products is itself a good, and in fact it is a public good: a good that may not be sufficiently produced in free markets if left to its own devices (although publications like Consumer Reports have made a good show of making a private good out of information). We can legally mandate the production of this good effecting a market control (as we do now via FDA, etc.), or we can distribute the onus for testing on those willing to volunteer because they have an vested interest in it. I haven't studied the problem in sufficient depth to determine which is a more viable option, but I suspect that we are currently more regulated than we need to be here.
Ultimately, as I suspect you're aware, all common goods require some control mechanism to mediate access and prevent abuse, and a few public goods may require a mandatory third party supported by all citizens; this control does not necessarily imply that a single monopoly must regulate all public goods (the government), simply that each common good be controlled by some mechanism (food and drugs by the FDA, the environment by an environmental organization, the use of legal force by the judicial system, or some such distribution of powers) and that these various controls need not be subject to a single mandate.
No, capitalism is poor in any case where there are negative externalities. These externalities aren't factored into the cost of products, and thus are effectively subsidized. This can be true of both pub
And pure capitalism (the analog of communism) requires, among other things, perfect information, thus relying on humans who don't lie, cheat, or steal.
On the contrary, socialism requires perfect information in order to perfectly plan and allocate resources. Capitalism and free markets have hidden/implicit information which is transmitted via the price of goods; a manufacturer doesn't need to know why the price of steel went up, just whether it is now worth switching to aluminium.
Capitalism requires perfect information only if you want or need to make a perfect long-term decision every time; this is rarely necessary, but when it is important, the onus is on the person who values the good so highly. I have a hard time seeing why such a distributed, fault tolerant system is a bad thing.
Capitalism and free markets are poor at dealing with public goods (such as the environment), but public goods are the only contingency that needs special handling; the important question is: how many and which goods are public goods?
capitalism runs off of capital, which is excess value created by work that laborers have done (profit). So inherently, capitalism takes advantage of those people who are forced (or choose) to sell their labor for less than the value of what they produce.
Which is predicated on the assumption that value is an absolute, not a relative measure. Unfortunately, this assumption is clearly false, and this is why anti-capitalists towing the "exploitation" line are full of it.
Hell yes. They have obscene amounts of money.
I think you seriously overestimate MS, or any company for that matter. Disregarding the, IMO, ludicrous notion that MS even has enough money to buy all the ISPs, all the power companies, and all the cable companies in the entire world, the bureaucratic overhead of running such a monstrous organization already makes it non-competitive with smaller companies.
Trivially... With a more powerful transmitter to jam such radio signals. No FCC to stop them, right?
True, assuming an extremist libertarian position, then the FCC wouldn't exist. But do you honestly believe that MS, or insert other future monopoly, will set up radio transmitters in every locale of interest, and pay to run them 24/7 to ensure their dominance as an ISP? Do you have any idea how much money it would cost to power those transmissions so they cover a sufficiently large area? The power required is honestly obscene, and I think you'd be hard-pressed to prove that the profits made by being the only ISP outweigh cost of running the jammers.
Furthermore, such warfare tactics induce serious ill-will and would ensure that alternatives come hard and fast. Finally, radio is not the only transmission medium; there is satellite, line of sight optical networks, and wide-spectrum radio systems. Developing and running a wide-spectrum jammer is even more expensive than narrow-band jammers; this monopoly would be fighting a never-ending guerilla war that they have no hope of ever winning.
As a child, it is highly unlikely you have done anything worthwhile. There is simply no reason why any responsible adult should give you (as a child) any "respect" at all.
Adults are no more deserving of respect than children. I know some children I respect more than some adults in fact. Any relationship between two parties has its own dynamic, but it's a dynamic that develops naturally through extended interaction between said parties; like trust, respect is earned, though there is a irreducible level of respect that every human being deserves. That goes for adults and children alike.
Witness the fact that Microsoft became large and powerful precisely *because* it abused its position, and its position still gives it huge amounts of leverage against encroachment by these open standards.
Doubtful. At the time, DOS was one of the only extremely cheap OSs that took personal computing seriously, in particular for business use; most everyone else was still focused on mainframes for business. If anything, MS demonstrated the power of first-mover advantage, because by the time IBM and Compaq recognized their error, MS was the business platform.
I agree that MS used predatory practices to maintain their stranglehold, but that's a whole separate issue which I already argued has been adequately tackled by open source.
I think that--in a Libertarian world--far more companies would maintain their profitability by abusing the system than would lose their profitability through such abuse.
I'm not sure it can be legitimately labeled "abuse", and particularly not in a libertarian world. MS and OEMs have a supplier/customer relationship, and if MS wants to make demands of their customers, they're within their rights to do so. OEMs will lose profitability only when MS' demands become so onerous as to cost OEMs more than they could make by selling MS software; otherwise, OEMs are still profiting from their agreement with MS, and it's up to them to decide whether the margin is too slim too warrant acquiescing to MS. Before Linux's push to the desktop there were few serious alternatives, and that need caused people to create one. And it's working: this threat is causing MS to re-evaluate their position, and has produced a legitimate alternative platform. Problem solved.
In conclusion, it's irrelevant if more companies will be profitable due to "predatory practices" than would lose money; the real question is whether the situation is self-correcting, and I've made a legitimate argument that it is. I haven't heard a strong argument why monopolies require government intervention because they are not self-correcting.
There is obscene amounts of evidence that the opposite is true. The more they abuse their position, the more they can assure no competition can possibly spring up.
I'd be interested to read about this evidence. Monopolies are generally toppled by competition, either from outside of their market (such as aluminium competing with the old steel monopolies), or from within their market once their abuse goes too far; in the software world, the obstacle of Microsoft seemed insurmountable, such that no one could ever envision being price competitive. Thus, a grassroots volunteer effort ended up challenging them, since even Microsoft could never hope to beat a $0 price point.
So I'd say there's also abundant evidence that regardless of how entrenched a monopoly may seem, they'll only last as long as they are providing value to someone above and beyond their competition. In that case, where is the need for regulation?
Just wait until Microsoft buys your ISP, which then bans users from visiting web sites hosting open source code.
Then Google, which has already been buying fibre across the continent and which depends on open source software, will offer an alternative. Does MS have enough money to purchase all the power companies when they start offering broadband over powerlines too? Are they going to buy the cable and the telecom companies? How can they stop a grassroots, community wireless ISP? Does MS really have the resources to buy every ISP on the planet?
I think it's a very narrow and pessimistic view that monopolies can only be controlled and overthrown by another monopoly, in this case, the government.