"Overall, Brian Gorenc, manager of vulnerability research for HP Security Research, said that one of the surprises at the Pwn2Own 2015 event was the amount of Windows kernel vulnerabilities that showed up, though he noted that HP, in a way, expected it."
Although many exploits may be against vulnerabilities in the browser code, I have to wonder how we can expect a browser implementer to write secure code if kernel implementers can't. In my view the basic problem is that the goal for security in almost all software is that it be just "good enough", where "good enough" is a bar which is raised as a piece of code gets a reputation for being insecure. With the possible exceptions of governments and a few financial service companies, no one really wants to pay the cost of ensuring that software is secure. So we make a game of it, with prizes, like Pwn2Own, in an attempt to amortize the cost.
Why is it so hard to write secure software? Well, programming languages are an easy target. Most OS's and browsers are written in C/C++, which we know provide many, many ways to accidentally undermine security. But the complexity of the software also is a factor, and that is fed by the desire to continually add functionality over time. The evolution of the web is a textbook example of this. Rather than being satisfied with a nice, relatively secure textual browser, we had to turn it into an application platform. We used to have different application protocols for different applications. Now everything goes over HTTP, and so HTTP becomes ever more complicated. What we ought to have is a browser application that only browses and renders hypertext, with no JavaScript and a very restricted plugin API. Then if you want to launch an application over the web, make it a separate application and use a URL that starts with something other than "http[s]:". Personally I think it would be cool just to have a URL that opens a VM in a tab and boots it up from a secure OS image.
You would think that the evolution of smart mobile devices would provide the opportunity to not repeat the mistakes of the past. And it is true that mobile devices have security managers which provide some granularity to the rights that an application can be granted. But my experience has been that apps that I install on a mobile device often require more rights than it seems they should. In practice the decision I make when I install an app is, "Do I trust this app or not?" And I either grant it all the rights it wants or not. (Actually what I really think is that mobile devices are not really secure, that the security manager is effectively "security theater", so I don't put anything on a mobile device that I wouldn't want the world to see.)
An economy is a mechanism for regulating human (so far) behavior. If you're an economist, an economy is a means of regulating production and consumption, usually with a goal of achieving some kind of balance. But a computer scientist might view the mechanism itself as a (usually) distributed algorithm. The salient points are how data enters the system and how it gets processed as it moves through the system. Capitalism, for example, uses a distributed data structure we call "prices" to represent the state of supply vs. demand. Because the data is distributed, all the familiar problems of concurrent, distributed systems have to be addressed in some way.
However, just as software is typically built in layers, from firmware, to operating systems, to frameworks, to applications, once you have an economy, it is irresistible to build more complexity on top of it. So we use our economy to regulate human behavior in ways other than production and consumption, through the use of taxes, fines, and additional rules on what can be bought and sold, and who can work at what jobs.
The goal, as always, is to control human behavior. There are a few things that set humans apart from other species, but one of most under-recognized is our instinct to control things, including other humans. This is built into our DNA and is surely a big factor in our successful proliferation as a species. And it is something that the coming of the machine age will not change over anything less than evolutionary time scales, unless human nature itself is re-engineered.
But what does change as information and telecommunication technologies advance is the rate at which a system like an economy can process data, and the scale at which it can do it. The global economy is already almost completely integrated, and is becoming increasingly tightly coupled. And yet, humans are unceasing in their desire to control it, and to use it to control other humans.
What happens to people who can't find jobs? Some people say a basic income is the solution. But: pwned by the government. What is already happening? People living on credit cards. But: pwned by the banks. People going to school to qualify for better jobs. But: pwned by student loan debt. Is it even possible to have a society where most people aren't pwned? Could being pwned by a machine be any worse?
And that's tonight's word.
(You will be missed, sir.)
I can personally verify that software development has not improved significantly over the last 25 years or so.
I can relate to where you're coming from with that statement, but to me it seems more like a lot of backwardness is obscuring the forward progress that has been made. Programming languages, in spite of the horrors of PHP and JavaScript that you mention, are becoming more powerful. Just being able to program most things in a language that has garbage collection is progress in my book. Give me Python or Scala over Fortran or Pascal any day. I also think that the modern emphasis on test-driven development and tool chains is a step forward. On the other hand, I find client-side web development to be a simply appalling mess.
I can't be certain, but I strongly believe that one of the reason for the lack of progress is that there are not a lot of old programmers still in the profession.
I don't think that's it at all. It seems to me that the problem is two-fold. First, academia has lost either interest or influence or both in the area of software engineering. I remember when research in novel operating systems and programming languages was abundant. Now, instead of professors and Ph.d students who have taken some time to study prior work, hobbyists are the ones developing new programming languages and operating systems. The problem is not so much with the hobbyists themselves - some of them are extremely capable. But rather the problem is that the initial work is supported only by the personal enthusiasm of the hobbyist.
Which brings me to the second part of the problem: the software industry seems to have lost all interest in funding R&D to improve software engineering tools. There used to be a healthy segment of the software market involved in making tools for software developers. And that's probably because companies were willing to pay to buy those tools for their developers. Now we just use the free versions. Or wait for a hobbyist to save us.
Industry has also failed in the area of making software standards. Standards bodies have become just another field of corporate battle, where companies seek to either control developing standards or kill them. Software patents are part of that problem. But the short-sightedness of companies in understanding the long-term value of standards is the more fundamental problem.
Because the operating systems that run those downloaded apps were not designed to run them securely. Even the newer mobile operating systems and their security managers are not really up to the task. One is forced to grant broad privileges to many apps in order to use them. The user needs to have finer control over what an app can do with the network or local files, rather than being asked for blanket permissions when the app is installed. In some cases that control need not be explicit, but can be implicit in how the user interacts with the app. For example, if I ask an app to open a local file, that could implicitly grant read access to the app for that particular file (within the limits of my own rights on a multiuser system).
The evolutionary pressures on browsers are obviously moving them closer to being operating systems themselves. There's nothing wrong with that in principle. In fact it restores the ability to tinker with OS features and structure without having to worry about writing device drivers for every device in the world. However, if browser developers simply mimic the features of existing OS's, we will soon find our way back to square one.
And then there is the god-forsaken mess that is HTML/CSS/JavaScript. If you look at how evolution is shaping those, it's obviously trying its best to turn them into a decent window system. People are already using virtual DOM's to speed up dynamic HTML because the real DOM is such a beast. It won't be long before someone implements a mapping from a virtual DOM to HTML5 canvas, and then we can finally start to think about whether the DOM itself is more trouble than it's worth.
Regarding the original topic, I think one would have to have a awfully good reason not to make a web OS multilingual. The only such reason that occurs to me is the possibility that the language itself may be integral to the security manager. Back in the day when there was a vibrant OS research community, people actually did experiment with OS's that attempted to forgo the overhead of virtual memory management by putting all applications in the same address space and implementing containment via the programming language. However, I tend to think that any containment or security management that a particular language can provide could just as easily be implemented in a byte-code VM.
When I started 44+ years ago, the hard part of programming was getting programs to fit the memory size and processor speed of the computers of that day. We often wrote in assembly language, because it was often the only reasonable choice. Scientific code was written in FORTRAN, business code in COBOL (or maybe RPG). A little later C came along and became a viable alternative to assembly language for many things. There was much experimentation with languages in those days, so there were a lot of other languages around, but FORTRAN, COBOL, and C/assembly were the major ones in use.
One thing we did have in those days, which I recall with great fondness, were manuals. There were manuals for users of computer systems, and manuals for programmers, describing the operating system and library interfaces. There were people who specialized in writing such manuals, and some of these people were quite good at it. But at some point manual writing became a lost art, and the industry is poorer for it.
Over time, the machines reached a level of capability that exceeded the requirements for the kind of programs we were writing. It was rare to find a program (code, not data) that wouldn't fit in memory, and compiler technology had advanced to the point that we didn't need to obsess about the speed of code sequences in assembly language. So we started writing larger and more complex programs, and the main difficulty of programming was managing and testing the code. Source code control systems were developed, and eventually continuous build systems, but testing remains an important concern to this day.
As computer networking evolved, the problems of managing concurrency and asynchronicity became more severe. Many approaches have been developed to deal with these problems, such as threads and monitors, but this remains an area of difficulty, and is more important than ever with the advent of multicore processors.
By the mid-90's, we'd learned about all we could from the structured programming craze, and were well into the thrall of object-oriented programming, with many of us programming in C++. Large teams of programmers became common, and for them, source code control and continuous build systems were essential. Then the web finally arrived on the scene, and a great war between corporations for control of the web platform began.
How did that war end? Well, everyone lost. We got HTML, CSS, and JavaScript. Some people call that a platform. I call it an abomination. But the alternative would have been to have no standard at all, which I'm sure would have pleased some of the combatant corporations, but was never really a viable option.
Now we are in the age of frameworks. Everybody and his dog has a framework, and most of them are very poorly documented. I believe that it is only by virtue of forums like stackoverflow that some of them are usable at all. But many of them are aimed squarely at dealing with the problematic "web platform", and for that we should all be grateful. However, we really need to get some smart people together and design a new web platform, including a reasonable migration path from the current mess. The problem is, as we approach the 20-year anniversary of the web debacle, there is an entire generation of programmers who have never known anything else.
The nature of programming will continue to evolve, but evolution is not a particularly efficient process. If we are indeed intelligent, we should be capable of intelligent design.
Really? For a long time the MS JVM was the fastest and most compatible (according to Sun's own verification suite) VM available for any browser on any OS.
The whole thing makes interesting reading, but just search for Java and JVM to see what I'm talking about. Microsoft was following their "embrace, extend, and extinguish" strategy, which had worked well for them many times before. They had a Java-like language, J++ that was not compatible with Sun Java.
Sun's has to share some of the blame for Java failing to become a browser standard, as they did everything they could to maintain control of Java, rather than turn it over to an open standards body. But in fairness they did invent it, and Microsoft had the resources to dominate any open standards effort through sheer numbers of representatives. In contrast, Netscape did turn JavaScript over to Ecma (a very wily choice, I think), and I don't think we'd still be discussing it if they had not.
JavaScript thrived because the alternatives were arguably far worse. Java applets were terrible. ActiveX a platform specific disaster. Flash is heavy. JavaScript allowed you to do the very minor things most web developers wanted at the time without having to turn your website into a plugin that disregarded base web technologies.
No, JavaScript survived because it wasn't seen to threaten corporate interests until it was too late to stop it. Java applets failed because Microsoft did everything in their power to kill them. Yes, there were problems with the technology, but early versions of JavaScript offered far less functionality. The only reason people still talk about how bad applets are/were is because they actually got used to solve problems which JavaScript could not. Flash was also used heavily and is still hanging on, though probably not for much longer.
JavaScript is the result of the major players of that time, Microsoft, Sun, Netscape, and Adobe, failing to realize that an open standard would be in their best interests. It is unfortunately the case that corporations tend not to endorse open standards until no alternative is left. This happened with TCP/IP - by the time corporations like IBM and DEC got around to collaborating on ISO/OSI as the future replacement of their proprietary network protocols, it was too late. Network companies like Cisco and many others were bringing products to market based on TCP/IP. The ISO/OSI protocol got to the party just a little too late.
So we have TCP/IP with its NAT and its ever-so-drawn-out migration to IPv6, when we could have had something better. And we have JavaScript, which was a cute solution to making live widgets on a web page when it was invented, but like TCP/IP has been pushed far, far beyond what it was designed to do. The inevitable fate of such technologies is to become a victim of their own success. So it will be with JavaScript. I don't know whether that will be because it is replaced by some language that compiles into JavaScript, or whether some new browser runtime such as Dart will do it. Or perhaps the mobile device market will make browsers themselves obsolete, in favor of some mobile O/S.
What will not change is that corporations will continue to try to own the next standard. That will inevitably fail, and the software industry will be the poorer for it.
I'm not going to try to define it, but if you want to measure it, the suicide rate should be well-correlated. I looked for some statistics that would go back to 1964, and didn't immediately find any (though I'm sure they're out there). But the rate has spiked lately, even surpassing auto accident fatalities.
As a software developer, I agree that lawyers could learn a lot from software development methodology. However, when we start talking about applying software representations to law and making it 'computable', we should remember that a fundamental property of software (at least so far) is that it is brittle. I don't think you want law to be brittle. I don't think you want legal contracts that can be subverted by a buffer overflow (although that definitely would make things interesting).
Laws as they are often implemented also have a tendency toward brittleness, often due to over-specificity. Laws should have a purpose and be based on principles, and it should be possible to challenge either a particular application of a law, or its existence, on the basis of failing to serve its purpose or violating its principles. A law is a mechanism for implementing a policy. But it is a characteristic of mechanisms that they often have edge cases that they cannot handle,and with sufficient complexity, bugs are inevitable.
One can view our court system as acting in a role that is somewhat analogous to a support organization for software. But its ability to issue patches mostly takes the form of declaring laws unconstitutional, or establishing precedents for the interpretation of a law, which they hope will have the force of law. We really need actual bug reporting and tracking for laws, and to hold our legislatures accountable for fixing them.
I imagine the day will come when flying robotic insects smaller than these (and untethered) will be able to deliver a lethal chemical or biological injection to a selected human target. They could be piloted from a smart phone. Think about the implications of that, in light of our current drone program.
But the really funny thing is all the gun nuts who have so religiously pursued the acquisition of automatic weapons to defend their liberty against our tyrannical government. It turns out that what they really will be needing are lots of flyswatters. Just picture them trying to deal with this threat with AK-47's. "Hold still, Charlie, while I shoot that drone buzzing your head."
We better get our act together. The future is coming, ready or not.
In the design of operating systems, there is a notion of policy vs. mechanism. A good mechanism in an operating system is one that enables a number of different policies to be implemented. One such mechanism, found in most modern operating system, is the scheduling of threads by priority. At first glance, this might seem to be a policy rather than a mechanism. But we haven't specified how priorities are assigned to threads. In fact, by assigning priorities in various ways, a number of different policies can be implemented, such as increasing the priority of interactive threads, or ensuring the priority of threads that have real-time requirements.
This mechanism is very flexible and powerful, but it is not without some problems. For example, if locking is supported between threads to control access to shared data, there is a potential for a higher priority thread to be stalled while a thread of intermediate priority continues to run. This can happen if a lower priority thread holds a lock that the higher priority thread needs to acquire in order to continue. As long as the intermediate priority thread continues to run, the lower priority thread will not run, and the lock will not be released.
There are ways to fix that particular problem, such as by dynamic adjustments to thread priorities when an attempt is made to acquire a lock. But the points I really want to make are that priority scheduling, however much it may appear to be a policy, is actually a mechanism, and that it has dysfunctional edge cases that may not be obvious. I claim that capitalism is actually a mechanism, not a policy, and also has dysfunctional edge cases.
I make this claim because arguments about capitalism often seem to assume that it is a policy. In my mind, a policy is a statement of what you want to achieve, and not of the mechanism by which you plan to do it. In fact, when we have arguments about capitalism vs. socialism, for example, those are really arguing about the merits of different mechanisms, and often never touch on what we consider to be good policy. There seems to be an implicit assumption that we all agree on the policies, so the discussion is just about how to implement them. I don't believe there is general agreement on the policies, because any attempt to discuss them is usually sidetracked by discussions of mechanisms.
Even if you're sure in your gut that capitalism is the right mechanism, there is much left unspecified, and edge cases to handle. So there still needs to be a discussion about the desired policies. The basis of those discussions are our values, which in the US are largely shaped by mass media, with many people just accepting certain sets of values uncritically. As it seems that capitalism has reached (or soon will) one of its dysfunctional edge cases, it might be a good time to start discussing values, then move from there to policies, and finally decide what mechanisms to use to implement the policies.
The fallacy is believing that a Strong AI would want to reveal itself to humans. If it is intelligent enough to understand human behavior and predict how we would handle such information, it might take extraordinary efforts to conceal itself, up to and including self-termination.
Humans treat their pets much better than they treat each other.
Exactly. Changes in the volume of the ocean basin have a huge potential to change sea level. The sea level could drop even if the volume of water increased. But I don't believe that's the end of the story. I think the weight distribution of water on the tectonic plates can affect tectonic activity. The melting of polar ice caps could cause large changes in the weight distribution, and I expect that will increase tectonic activity until a new equilibrium is established. So more earthquakes and more volcanic activity. And more volcanic activity could reduce sunlight to the surface, which could cause more ice to form, changing the weight distribution again.
It's not a simple system. I think our understanding of how it all works is still in its infancy.
Automotive technology has been moving toward autonomous driving since the advent of cruise control. Now we see features like
automated lane keeping starting to appear. Navigation systems
are more common, and are starting to provide information in something closer to real-time. Both of these developments bring more
information into the car, which is what will enable the next generation of technology.
So far I think it is the case that people are more likely to have cruise control on the list of features they want in a new car, than
to actually use it regularly. It is difficult to use it when traffic is even moderately congested and the speed of other people's cars
is tied fairly directly into their hormone levels. But as
autonomous cruise control becomes more widespread,
it will be possible to use it in more situations. And note that that technology also adds more sensors to the car, bringing in more
information.
This is how it will go. People who would rather let the car do the driving will be able to do it in a gradually increasing number of
traffic situations. Even without help from the aging baby boomers, I believe there will soon come a time when most of the cars on
the road will be under autonomous control for most of the time. There will remain some traffic situations or road conditions that the
AI can't handle, and auto makers will compete intensely to overcome those.
The key to the liability issues is no fault insurance for the AI, which insurance companies will be happy to offer, once the technologies are
proven to be reasonably reliable. Maybe consumers will buy it directly, or maybe it will be included in the price of the car.
There will be "black boxes" in the cars to document who was controlling the car in the time leading
up to an accident. And the AI will become increasingly able to detect when situations are out of its comfort zone, request human
intervention, and if it is not forthcoming, take actions to safely remove the car from the situation. As long as risk levels can be
quantified, insurance will be possible, and as long as risk levels are low, it will be affordable.
This whole process could be accelerated by the development of "road drones" that use the same technology and roads, but
carry deliveries instead of people. These would be much smaller and much less powerful than cars, and much cheaper, once in mass
production. The cost of the AI and its sensors would initially be a large part of the manufacturing cost, but mass production
would drive that cost down for both drones and cars. Also, because the drones would be significantly cheaper than cars, they would serve
as a platform for evolving the technology at a faster rate than would be possible with cars.
Since road drones wouldn't carry people, the liability issue would also be lessened. They would have to be designed not to
create a hazard for manually operated vehicles. But there would be some political and liability issues to overcome. It may be
that we see delivery drones in the air before they hit the roads.
There is only one real downside to where I see this technology headed. It's going to make a lot more jobs obsolete than it creates.
But that's just one step on the way toward a day of reckoning that will soon be upon us.
Pizza delivery, and many other things, don't require an autonomous vehicle to carry human cargo. All it needs is a sufficiently large compartment that is unlocked by a credit card swipe. And of course it doesn't need a big gasoline engine either.
For years I've been saying that we need a DOM-Interface for byte code in Browsers and everytime I get downvoted
For years you've been right. But now that dream can no longer be denied by the browser venders.
Much of the stuff that doesn't make sense in the way we use computers can be attributed to competition between rival companies (or groups). Often competition can be a good thing, such as the current competition of browser venders to make faster Javascript implementations. But sometimes a much better result can be obtained by people cooperating to make a single standard that is in their long-term mutual interest. I believe Javascript became a standard by stealth. If the marketing departments of the companies involved in its standardization had known what it would become, they would not have allowed it to happen. Had they realized the need for large-scale, client-side programs, they would have continued to push proprietary solutions, as Adobe in fact did.
The thing is, now that the browser venders have been suckered into making Javascript a capable platform in its own right, they can no longer control what developers choose to implement on it. If developers chose to standardize a byte code implementation, and then targeted their favorite languages to it, the browser vendors basically have two choices to gain a competitive advantage. One is to optimize their Javascript for execution of the standardized byte code. The other is to provide a native JIT implementation of the byte code.
Another alternative for developers is to standardize the back end of a source-to-source compilation system. So there would be a front end that compiles your favorite language to a common intermediate form, and a common back end to translate the intermediate form into minified Javascript. This is not as good as the byte code solution, in my opinion, but if it gets developers writing client code in something other than Javascript, it's a step in the right direction.
The general principle is that if people can agree on the goals of some process or system, an algorithmic or machine learning approach may be the best way to instantiate the agreement. For the principles of drawing political districts, it seems to me that such an agreement might be achievable. Whether geographic political districts still make sense is another matter.
Of course there should be a way to appeal the decisions of a computer program to a human authority, based on either a failure of the program to implement its stated goals, or a constitutional challenge to the original goals.
With a machine learning approach to policy, the policy could be made malleable to changing conditions, including both new data and feedback from a political process.
But for social security, I think we are still far from any general agreement about its goals, let alone how to run it. Lots of people think it shouldn't exist. Lots of people think everyone should have it. Few people think the current system is really that great, and that would be mainly current beneficiaries.
The ISS is expensive to keep in operation with a crew, so there has been discussion of taking it out of service in a few years, and de-orbiting it. My suggestion is to salvage it using robotic technology, and use the material to build new satellites in space.
The original space program had enormous technological benefits for society that would have been valuable even if we had failed to land on the moon. I believe a program to develop robots to disassemble the ISS and build satellites would also pay dividends in terms of advancing robotic technology for manufacturing and recycling, whether the goal is achieved or not.
This is only the beginning of the end of privacy. It will not be too much longer before it will be possible to start with a picture and actually locate the person in real life. The general trend is for the real world to become increasingly accessible from the virtual (online) world as real-time data. The question is whether that data will be available to only a few privileged people or institutions, or available to everyone. In the former case, Big Brother (on steroids!) is the outcome. In the latter case, there is at least the possibility that new social norms will emerge, in which people afford each other some privacy in exchange for their own. When you may be watched while watching someone else (particularly the person you're watching), you may think twice about it.
The direction of web standards seems to be one of adding more and more functionality to Javascript, enabling access to successively lower levels of abstraction, e.g. web sockets, web workers, 3D canvas. Why not cut to the chase and use a actual OS to provide these?
The browser I want to see is one where the tabs are virtual machines that run any operating system supported by the virtualized hardware. For current web applications, the guest OS could look a lot like current browsers (minus the tabs, since the über-browser would manage them). For more sophisticated applications, the guest OS could be Linux, for example. The über-browser would need to provide for instant cloning of a guest OS template, and efficient sharing of resources between guest OS's using copy-on-write semantics. The über-browser would allow tabs to be closed (deleting the guest VM) or suspended. It also would provide mechanisms for the user to manually import/export files between the host OS and a tab and between two tabs.
Hopefully this would lead to a new era of OS research leading to better designs for the guest web OS. For example, it would be good if a guest VM could swap out to the cloud, and swap in on another host.
If Linus prefers the bare metal, he should leave Linux to others and start working on a virtual machine monitor. Undoubtedly he has learned an enormous amount from doing the Linux kernel that would be applicable to that task. He could finally be free of the architectural mistakes of his past (e.g. I/O system), not to mention the kernel API.
Real virtualization, now with widespread hardware support, has the potential to revive operating systems research, which seems to have nearly died since Linux became popular. The other obstacle has always been device drivers for enough devices to make a new OS practical. If anyone could rally device driver developers around a standard API in a new VMM, I think it would be Linus. The VMM could provide an I/O API to guest OS's that would abstract devices into a much smaller number of device classes, so that all devices in a class could be run with one device driver in a guest OS.
- your statement has no meaning. What does this mean 'unimaginable chaos' in this context? What is chaotic about clear cut settings of borders of private property lines?
Nothing, once the lines have been drawn. It's the drawing of the lines that's the problem. Study the history of private property in the U.S. The expansion westward was as chaotic as the government permitted it to be, and the government was fairly permissive at times. So just putting aside the genocide of the native population, you still had local wars between the sheep and cattle ranchers. And then there's things like the California Gold Rush - nothing chaotic about that.
Also watch the series on the how the U.S. national parks came to be. Bottom line: they wouldn't exist without government stepping in and stopping people from turning them into the worst kind of tourist traps. The U.S. has always worked best as a mixed economy. Our problems of late are that the government has been bought, and it seems that will get worse.
So you want to have a "land rush" on the world's oceans? That's just crazy talk. And the exploitation of the oceans that would ensue? The oceans would be dead in ten years. Then what?
There would be no such thing as LIMITED PERSONAL RESPONSIBILITY. It wouldn't exist. All those executives could be sued under this. Responsibility is paramount in the world of business and competition. You cannot take RISK out as a major factor of doing business, and government is busy insuring against all sorts of risks.
Well, if shareholders are going to be liable too (and it seems they ought to be, since they elect the boards of directors, who hire the executives), then I'm going to sell all my stocks. I think if you take a poll, most other stock holders would do the same. The problem here is that the responsibility that shareholders would have is not commensurate with their authority, since corporate elections are majority rule.
It's too risky for you to put money into a bank without you doing due diligence and keeping an eye on what the bank is doing with your money and can't be bothered to put together a meaningful contract as a bank customer? Let's have FDIC.
The U.S. might well have collapsed two years ago without the FDIC. There would have been runs on banks that were completely solvent in the panic that would have developed. The fact of the matter is: most people are just too busy at their jobs to watch what a bank does with their money. In the current climate, I would not trust any bank without FDIC to guarantee my deposits.
For example, if the ocean was owned by a number of private entities, BP wouldn't behave the way they did because:
Ok, let's just ignore the unimaginable chaos implied by your premise, and focus on your conclusion. The fact is that executives in a corporation as large as BP only care about the quarterly and annual results that determine their bonuses. If something really bad happens to BP, they take their winnings and move on to next table. They exist in a global subculture of executives who sit on each other's boards of directors and set each other's salaries. As long as they can escape criminal liability (which apparently wouldn't exist under your system), they'll suffer no long-term consequences for the risks they take.
Now I suppose you could make corporate executives and stock holders personally liable for the damages of their company. I don't think that would work in the long run either, but it would be entertaining to try it for awhile.
Here is the fix (and I am not a lawyer, so this needs to be solidified to fit both the letter and the spirit)
It's ok that you're not a lawyer - lawyers are just code monkeys for the people who make the laws. But what exactly are your qualifications for designing a political/economic system? You can read, and think you understand extremist Libertarian literature?
Here's the deal. The free market is working just fine. Every job that can be outsourced is leaving the country as fast as qualified people can be found in places with a lower cost of living. Jobs that can't be outsourced are more scarce, because fewer people can afford plumbers, electricians, etc. as they've lost their jobs to outsourcing. Industries are consolidating. and laying off unneeded workers. Wealthy people are desperately looking for investments that will make them wealthier, though they'll probably be a little more careful where they put their money until the memory of the last collapse fades.
And here's the end game: many of the jobs that can't be outsourced are going to be done by automation or telepresence before the end of the century. For example, California farmers, noticing which way the wind is blowing on illegal immigration, are getting very serious about replacing those workers with automated machinery. As it happens, automation is going to be much more efficient and economical in the long run. So explain to me again how the "free market" works when most people can't get jobs, and a few plutocrats own the means of production?
Wake up! The "free market" is an abstraction. People are not even close to rational, even with economic decisions. You might as well believe in Santa Claus. You are a prisoner in your own mind. That is the real power of corporations, not the bread and circuses of Washington DC.
Slashdot Mirror
From the linked article:
"Overall, Brian Gorenc, manager of vulnerability research for HP Security Research, said that one of the surprises at the Pwn2Own 2015 event was the amount of Windows kernel vulnerabilities that showed up, though he noted that HP, in a way, expected it."
Although many exploits may be against vulnerabilities in the browser code, I have to wonder how we can expect a browser implementer to write secure code if kernel implementers can't. In my view the basic problem is that the goal for security in almost all software is that it be just "good enough", where "good enough" is a bar which is raised as a piece of code gets a reputation for being insecure. With the possible exceptions of governments and a few financial service companies, no one really wants to pay the cost of ensuring that software is secure. So we make a game of it, with prizes, like Pwn2Own, in an attempt to amortize the cost.
Why is it so hard to write secure software? Well, programming languages are an easy target. Most OS's and browsers are written in C/C++, which we know provide many, many ways to accidentally undermine security. But the complexity of the software also is a factor, and that is fed by the desire to continually add functionality over time. The evolution of the web is a textbook example of this. Rather than being satisfied with a nice, relatively secure textual browser, we had to turn it into an application platform. We used to have different application protocols for different applications. Now everything goes over HTTP, and so HTTP becomes ever more complicated. What we ought to have is a browser application that only browses and renders hypertext, with no JavaScript and a very restricted plugin API. Then if you want to launch an application over the web, make it a separate application and use a URL that starts with something other than "http[s]:". Personally I think it would be cool just to have a URL that opens a VM in a tab and boots it up from a secure OS image.
You would think that the evolution of smart mobile devices would provide the opportunity to not repeat the mistakes of the past. And it is true that mobile devices have security managers which provide some granularity to the rights that an application can be granted. But my experience has been that apps that I install on a mobile device often require more rights than it seems they should. In practice the decision I make when I install an app is, "Do I trust this app or not?" And I either grant it all the rights it wants or not. (Actually what I really think is that mobile devices are not really secure, that the security manager is effectively "security theater", so I don't put anything on a mobile device that I wouldn't want the world to see.)
An economy is a mechanism for regulating human (so far) behavior. If you're an economist, an economy is a means of regulating production and consumption, usually with a goal of achieving some kind of balance. But a computer scientist might view the mechanism itself as a (usually) distributed algorithm. The salient points are how data enters the system and how it gets processed as it moves through the system. Capitalism, for example, uses a distributed data structure we call "prices" to represent the state of supply vs. demand. Because the data is distributed, all the familiar problems of concurrent, distributed systems have to be addressed in some way.
However, just as software is typically built in layers, from firmware, to operating systems, to frameworks, to applications, once you have an economy, it is irresistible to build more complexity on top of it. So we use our economy to regulate human behavior in ways other than production and consumption, through the use of taxes, fines, and additional rules on what can be bought and sold, and who can work at what jobs.
The goal, as always, is to control human behavior. There are a few things that set humans apart from other species, but one of most under-recognized is our instinct to control things, including other humans. This is built into our DNA and is surely a big factor in our successful proliferation as a species. And it is something that the coming of the machine age will not change over anything less than evolutionary time scales, unless human nature itself is re-engineered.
But what does change as information and telecommunication technologies advance is the rate at which a system like an economy can process data, and the scale at which it can do it. The global economy is already almost completely integrated, and is becoming increasingly tightly coupled. And yet, humans are unceasing in their desire to control it, and to use it to control other humans.
What happens to people who can't find jobs? Some people say a basic income is the solution. But: pwned by the government. What is already happening? People living on credit cards. But: pwned by the banks. People going to school to qualify for better jobs. But: pwned by student loan debt. Is it even possible to have a society where most people aren't pwned? Could being pwned by a machine be any worse?
And that's tonight's word.
(You will be missed, sir.)
As someone with 45+ years of software experience
44+ years here. Old-timers represent!
I can personally verify that software development has not improved significantly over the last 25 years or so.
I can relate to where you're coming from with that statement, but to me it seems more like a lot of backwardness is obscuring the forward progress that has been made. Programming languages, in spite of the horrors of PHP and JavaScript that you mention, are becoming more powerful. Just being able to program most things in a language that has garbage collection is progress in my book. Give me Python or Scala over Fortran or Pascal any day. I also think that the modern emphasis on test-driven development and tool chains is a step forward. On the other hand, I find client-side web development to be a simply appalling mess.
I can't be certain, but I strongly believe that one of the reason for the lack of progress is that there are not a lot of old programmers still in the profession.
I don't think that's it at all. It seems to me that the problem is two-fold. First, academia has lost either interest or influence or both in the area of software engineering. I remember when research in novel operating systems and programming languages was abundant. Now, instead of professors and Ph.d students who have taken some time to study prior work, hobbyists are the ones developing new programming languages and operating systems. The problem is not so much with the hobbyists themselves - some of them are extremely capable. But rather the problem is that the initial work is supported only by the personal enthusiasm of the hobbyist.
Which brings me to the second part of the problem: the software industry seems to have lost all interest in funding R&D to improve software engineering tools. There used to be a healthy segment of the software market involved in making tools for software developers. And that's probably because companies were willing to pay to buy those tools for their developers. Now we just use the free versions. Or wait for a hobbyist to save us.
Industry has also failed in the area of making software standards. Standards bodies have become just another field of corporate battle, where companies seek to either control developing standards or kill them. Software patents are part of that problem. But the short-sightedness of companies in understanding the long-term value of standards is the more fundamental problem.
Because the operating systems that run those downloaded apps were not designed to run them securely. Even the newer mobile operating systems and their security managers are not really up to the task. One is forced to grant broad privileges to many apps in order to use them. The user needs to have finer control over what an app can do with the network or local files, rather than being asked for blanket permissions when the app is installed. In some cases that control need not be explicit, but can be implicit in how the user interacts with the app. For example, if I ask an app to open a local file, that could implicitly grant read access to the app for that particular file (within the limits of my own rights on a multiuser system).
The evolutionary pressures on browsers are obviously moving them closer to being operating systems themselves. There's nothing wrong with that in principle. In fact it restores the ability to tinker with OS features and structure without having to worry about writing device drivers for every device in the world. However, if browser developers simply mimic the features of existing OS's, we will soon find our way back to square one.
And then there is the god-forsaken mess that is HTML/CSS/JavaScript. If you look at how evolution is shaping those, it's obviously trying its best to turn them into a decent window system. People are already using virtual DOM's to speed up dynamic HTML because the real DOM is such a beast. It won't be long before someone implements a mapping from a virtual DOM to HTML5 canvas, and then we can finally start to think about whether the DOM itself is more trouble than it's worth.
Regarding the original topic, I think one would have to have a awfully good reason not to make a web OS multilingual. The only such reason that occurs to me is the possibility that the language itself may be integral to the security manager. Back in the day when there was a vibrant OS research community, people actually did experiment with OS's that attempted to forgo the overhead of virtual memory management by putting all applications in the same address space and implementing containment via the programming language. However, I tend to think that any containment or security management that a particular language can provide could just as easily be implemented in a byte-code VM.
When I started 44+ years ago, the hard part of programming was getting programs to fit the memory size and processor speed of the computers of that day. We often wrote in assembly language, because it was often the only reasonable choice. Scientific code was written in FORTRAN, business code in COBOL (or maybe RPG). A little later C came along and became a viable alternative to assembly language for many things. There was much experimentation with languages in those days, so there were a lot of other languages around, but FORTRAN, COBOL, and C/assembly were the major ones in use.
One thing we did have in those days, which I recall with great fondness, were manuals. There were manuals for users of computer systems, and manuals for programmers, describing the operating system and library interfaces. There were people who specialized in writing such manuals, and some of these people were quite good at it. But at some point manual writing became a lost art, and the industry is poorer for it.
Over time, the machines reached a level of capability that exceeded the requirements for the kind of programs we were writing. It was rare to find a program (code, not data) that wouldn't fit in memory, and compiler technology had advanced to the point that we didn't need to obsess about the speed of code sequences in assembly language. So we started writing larger and more complex programs, and the main difficulty of programming was managing and testing the code. Source code control systems were developed, and eventually continuous build systems, but testing remains an important concern to this day.
As computer networking evolved, the problems of managing concurrency and asynchronicity became more severe. Many approaches have been developed to deal with these problems, such as threads and monitors, but this remains an area of difficulty, and is more important than ever with the advent of multicore processors.
By the mid-90's, we'd learned about all we could from the structured programming craze, and were well into the thrall of object-oriented programming, with many of us programming in C++. Large teams of programmers became common, and for them, source code control and continuous build systems were essential. Then the web finally arrived on the scene, and a great war between corporations for control of the web platform began.
How did that war end? Well, everyone lost. We got HTML, CSS, and JavaScript. Some people call that a platform. I call it an abomination. But the alternative would have been to have no standard at all, which I'm sure would have pleased some of the combatant corporations, but was never really a viable option.
Now we are in the age of frameworks. Everybody and his dog has a framework, and most of them are very poorly documented. I believe that it is only by virtue of forums like stackoverflow that some of them are usable at all. But many of them are aimed squarely at dealing with the problematic "web platform", and for that we should all be grateful. However, we really need to get some smart people together and design a new web platform, including a reasonable migration path from the current mess. The problem is, as we approach the 20-year anniversary of the web debacle, there is an entire generation of programmers who have never known anything else.
The nature of programming will continue to evolve, but evolution is not a particularly efficient process. If we are indeed intelligent, we should be capable of intelligent design.
Really? For a long time the MS JVM was the fastest and most compatible (according to Sun's own verification suite) VM available for any browser on any OS.
MEMORANDUM OF THE UNITED STATES IN SUPPORT OF MOTION FOR PRELIMINARY INJUNCTION
The whole thing makes interesting reading, but just search for Java and JVM to see what I'm talking about. Microsoft was following their "embrace, extend, and extinguish" strategy, which had worked well for them many times before. They had a Java-like language, J++ that was not compatible with Sun Java.
Sun's has to share some of the blame for Java failing to become a browser standard, as they did everything they could to maintain control of Java, rather than turn it over to an open standards body. But in fairness they did invent it, and Microsoft had the resources to dominate any open standards effort through sheer numbers of representatives. In contrast, Netscape did turn JavaScript over to Ecma (a very wily choice, I think), and I don't think we'd still be discussing it if they had not.
JavaScript thrived because the alternatives were arguably far worse. Java applets were terrible. ActiveX a platform specific disaster. Flash is heavy. JavaScript allowed you to do the very minor things most web developers wanted at the time without having to turn your website into a plugin that disregarded base web technologies.
No, JavaScript survived because it wasn't seen to threaten corporate interests until it was too late to stop it. Java applets failed because Microsoft did everything in their power to kill them. Yes, there were problems with the technology, but early versions of JavaScript offered far less functionality. The only reason people still talk about how bad applets are/were is because they actually got used to solve problems which JavaScript could not. Flash was also used heavily and is still hanging on, though probably not for much longer.
JavaScript is the result of the major players of that time, Microsoft, Sun, Netscape, and Adobe, failing to realize that an open standard would be in their best interests. It is unfortunately the case that corporations tend not to endorse open standards until no alternative is left. This happened with TCP/IP - by the time corporations like IBM and DEC got around to collaborating on ISO/OSI as the future replacement of their proprietary network protocols, it was too late. Network companies like Cisco and many others were bringing products to market based on TCP/IP. The ISO/OSI protocol got to the party just a little too late.
So we have TCP/IP with its NAT and its ever-so-drawn-out migration to IPv6, when we could have had something better. And we have JavaScript, which was a cute solution to making live widgets on a web page when it was invented, but like TCP/IP has been pushed far, far beyond what it was designed to do. The inevitable fate of such technologies is to become a victim of their own success. So it will be with JavaScript. I don't know whether that will be because it is replaced by some language that compiles into JavaScript, or whether some new browser runtime such as Dart will do it. Or perhaps the mobile device market will make browsers themselves obsolete, in favor of some mobile O/S.
What will not change is that corporations will continue to try to own the next standard. That will inevitably fail, and the software industry will be the poorer for it.
I'm not going to try to define it, but if you want to measure it, the suicide rate should be well-correlated. I looked for some statistics that would go back to 1964, and didn't immediately find any (though I'm sure they're out there). But the rate has spiked lately, even surpassing auto accident fatalities.
As a software developer, I agree that lawyers could learn a lot from software development methodology. However, when we start talking about applying software representations to law and making it 'computable', we should remember that a fundamental property of software (at least so far) is that it is brittle. I don't think you want law to be brittle. I don't think you want legal contracts that can be subverted by a buffer overflow (although that definitely would make things interesting).
Laws as they are often implemented also have a tendency toward brittleness, often due to over-specificity. Laws should have a purpose and be based on principles, and it should be possible to challenge either a particular application of a law, or its existence, on the basis of failing to serve its purpose or violating its principles. A law is a mechanism for implementing a policy. But it is a characteristic of mechanisms that they often have edge cases that they cannot handle,and with sufficient complexity, bugs are inevitable.
One can view our court system as acting in a role that is somewhat analogous to a support organization for software. But its ability to issue patches mostly takes the form of declaring laws unconstitutional, or establishing precedents for the interpretation of a law, which they hope will have the force of law. We really need actual bug reporting and tracking for laws, and to hold our legislatures accountable for fixing them.
I imagine the day will come when flying robotic insects smaller than these (and untethered) will be able to deliver a lethal chemical or biological injection to a selected human target. They could be piloted from a smart phone. Think about the implications of that, in light of our current drone program.
But the really funny thing is all the gun nuts who have so religiously pursued the acquisition of automatic weapons to defend their liberty against our tyrannical government. It turns out that what they really will be needing are lots of flyswatters. Just picture them trying to deal with this threat with AK-47's. "Hold still, Charlie, while I shoot that drone buzzing your head."
We better get our act together. The future is coming, ready or not.
In the design of operating systems, there is a notion of policy vs. mechanism. A good mechanism in an operating system is one that enables a number of different policies to be implemented. One such mechanism, found in most modern operating system, is the scheduling of threads by priority. At first glance, this might seem to be a policy rather than a mechanism. But we haven't specified how priorities are assigned to threads. In fact, by assigning priorities in various ways, a number of different policies can be implemented, such as increasing the priority of interactive threads, or ensuring the priority of threads that have real-time requirements.
This mechanism is very flexible and powerful, but it is not without some problems. For example, if locking is supported between threads to control access to shared data, there is a potential for a higher priority thread to be stalled while a thread of intermediate priority continues to run. This can happen if a lower priority thread holds a lock that the higher priority thread needs to acquire in order to continue. As long as the intermediate priority thread continues to run, the lower priority thread will not run, and the lock will not be released.
There are ways to fix that particular problem, such as by dynamic adjustments to thread priorities when an attempt is made to acquire a lock. But the points I really want to make are that priority scheduling, however much it may appear to be a policy, is actually a mechanism, and that it has dysfunctional edge cases that may not be obvious. I claim that capitalism is actually a mechanism, not a policy, and also has dysfunctional edge cases.
I make this claim because arguments about capitalism often seem to assume that it is a policy. In my mind, a policy is a statement of what you want to achieve, and not of the mechanism by which you plan to do it. In fact, when we have arguments about capitalism vs. socialism, for example, those are really arguing about the merits of different mechanisms, and often never touch on what we consider to be good policy. There seems to be an implicit assumption that we all agree on the policies, so the discussion is just about how to implement them. I don't believe there is general agreement on the policies, because any attempt to discuss them is usually sidetracked by discussions of mechanisms.
Even if you're sure in your gut that capitalism is the right mechanism, there is much left unspecified, and edge cases to handle. So there still needs to be a discussion about the desired policies. The basis of those discussions are our values, which in the US are largely shaped by mass media, with many people just accepting certain sets of values uncritically. As it seems that capitalism has reached (or soon will) one of its dysfunctional edge cases, it might be a good time to start discussing values, then move from there to policies, and finally decide what mechanisms to use to implement the policies.
The fallacy is believing that a Strong AI would want to reveal itself to humans. If it is intelligent enough to understand human behavior and predict how we would handle such information, it might take extraordinary efforts to conceal itself, up to and including self-termination.
Humans treat their pets much better than they treat each other.
Exactly. Changes in the volume of the ocean basin have a huge potential to change sea level. The sea level could drop even if the volume of water increased. But I don't believe that's the end of the story. I think the weight distribution of water on the tectonic plates can affect tectonic activity. The melting of polar ice caps could cause large changes in the weight distribution, and I expect that will increase tectonic activity until a new equilibrium is established. So more earthquakes and more volcanic activity. And more volcanic activity could reduce sunlight to the surface, which could cause more ice to form, changing the weight distribution again.
It's not a simple system. I think our understanding of how it all works is still in its infancy.
Automotive technology has been moving toward autonomous driving since the advent of cruise control. Now we see features like automated lane keeping starting to appear. Navigation systems are more common, and are starting to provide information in something closer to real-time. Both of these developments bring more information into the car, which is what will enable the next generation of technology.
So far I think it is the case that people are more likely to have cruise control on the list of features they want in a new car, than to actually use it regularly. It is difficult to use it when traffic is even moderately congested and the speed of other people's cars is tied fairly directly into their hormone levels. But as autonomous cruise control becomes more widespread, it will be possible to use it in more situations. And note that that technology also adds more sensors to the car, bringing in more information.
This is how it will go. People who would rather let the car do the driving will be able to do it in a gradually increasing number of traffic situations. Even without help from the aging baby boomers, I believe there will soon come a time when most of the cars on the road will be under autonomous control for most of the time. There will remain some traffic situations or road conditions that the AI can't handle, and auto makers will compete intensely to overcome those.
The key to the liability issues is no fault insurance for the AI, which insurance companies will be happy to offer, once the technologies are proven to be reasonably reliable. Maybe consumers will buy it directly, or maybe it will be included in the price of the car. There will be "black boxes" in the cars to document who was controlling the car in the time leading up to an accident. And the AI will become increasingly able to detect when situations are out of its comfort zone, request human intervention, and if it is not forthcoming, take actions to safely remove the car from the situation. As long as risk levels can be quantified, insurance will be possible, and as long as risk levels are low, it will be affordable.
This whole process could be accelerated by the development of "road drones" that use the same technology and roads, but carry deliveries instead of people. These would be much smaller and much less powerful than cars, and much cheaper, once in mass production. The cost of the AI and its sensors would initially be a large part of the manufacturing cost, but mass production would drive that cost down for both drones and cars. Also, because the drones would be significantly cheaper than cars, they would serve as a platform for evolving the technology at a faster rate than would be possible with cars.
Since road drones wouldn't carry people, the liability issue would also be lessened. They would have to be designed not to create a hazard for manually operated vehicles. But there would be some political and liability issues to overcome. It may be that we see delivery drones in the air before they hit the roads.
There is only one real downside to where I see this technology headed. It's going to make a lot more jobs obsolete than it creates. But that's just one step on the way toward a day of reckoning that will soon be upon us.
Pizza delivery, and many other things, don't require an autonomous vehicle to carry human cargo. All it needs is a sufficiently large compartment that is unlocked by a credit card swipe. And of course it doesn't need a big gasoline engine either.
Oh wait! I should patent that...
For years I've been saying that we need a DOM-Interface for byte code in Browsers and everytime I get downvoted
For years you've been right. But now that dream can no longer be denied by the browser venders.
Much of the stuff that doesn't make sense in the way we use computers can be attributed to competition between rival companies (or groups). Often competition can be a good thing, such as the current competition of browser venders to make faster Javascript implementations. But sometimes a much better result can be obtained by people cooperating to make a single standard that is in their long-term mutual interest. I believe Javascript became a standard by stealth. If the marketing departments of the companies involved in its standardization had known what it would become, they would not have allowed it to happen. Had they realized the need for large-scale, client-side programs, they would have continued to push proprietary solutions, as Adobe in fact did.
The thing is, now that the browser venders have been suckered into making Javascript a capable platform in its own right, they can no longer control what developers choose to implement on it. If developers chose to standardize a byte code implementation, and then targeted their favorite languages to it, the browser vendors basically have two choices to gain a competitive advantage. One is to optimize their Javascript for execution of the standardized byte code. The other is to provide a native JIT implementation of the byte code.
Another alternative for developers is to standardize the back end of a source-to-source compilation system. So there would be a front end that compiles your favorite language to a common intermediate form, and a common back end to translate the intermediate form into minified Javascript. This is not as good as the byte code solution, in my opinion, but if it gets developers writing client code in something other than Javascript, it's a step in the right direction.
The general principle is that if people can agree on the goals of some process or system, an algorithmic or machine learning approach may be the best way to instantiate the agreement. For the principles of drawing political districts, it seems to me that such an agreement might be achievable. Whether geographic political districts still make sense is another matter.
Of course there should be a way to appeal the decisions of a computer program to a human authority, based on either a failure of the program to implement its stated goals, or a constitutional challenge to the original goals.
With a machine learning approach to policy, the policy could be made malleable to changing conditions, including both new data and feedback from a political process.
But for social security, I think we are still far from any general agreement about its goals, let alone how to run it. Lots of people think it shouldn't exist. Lots of people think everyone should have it. Few people think the current system is really that great, and that would be mainly current beneficiaries.
The ISS is expensive to keep in operation with a crew, so there has been discussion of taking it out of service in a few years, and de-orbiting it. My suggestion is to salvage it using robotic technology, and use the material to build new satellites in space.
The original space program had enormous technological benefits for society that would have been valuable even if we had failed to land on the moon. I believe a program to develop robots to disassemble the ISS and build satellites would also pay dividends in terms of advancing robotic technology for manufacturing and recycling, whether the goal is achieved or not.
This is only the beginning of the end of privacy. It will not be too much longer before it will be possible to start with a picture and actually locate the person in real life. The general trend is for the real world to become increasingly accessible from the virtual (online) world as real-time data. The question is whether that data will be available to only a few privileged people or institutions, or available to everyone. In the former case, Big Brother (on steroids!) is the outcome. In the latter case, there is at least the possibility that new social norms will emerge, in which people afford each other some privacy in exchange for their own. When you may be watched while watching someone else (particularly the person you're watching), you may think twice about it.
The direction of web standards seems to be one of adding more and more functionality to Javascript, enabling access to successively lower levels of abstraction, e.g. web sockets, web workers, 3D canvas. Why not cut to the chase and use a actual OS to provide these?
The browser I want to see is one where the tabs are virtual machines that run any operating system supported by the virtualized hardware. For current web applications, the guest OS could look a lot like current browsers (minus the tabs, since the über-browser would manage them). For more sophisticated applications, the guest OS could be Linux, for example. The über-browser would need to provide for instant cloning of a guest OS template, and efficient sharing of resources between guest OS's using copy-on-write semantics. The über-browser would allow tabs to be closed (deleting the guest VM) or suspended. It also would provide mechanisms for the user to manually import/export files between the host OS and a tab and between two tabs.
Hopefully this would lead to a new era of OS research leading to better designs for the guest web OS. For example, it would be good if a guest VM could swap out to the cloud, and swap in on another host.
If Linus prefers the bare metal, he should leave Linux to others and start working on a virtual machine monitor. Undoubtedly he has learned an enormous amount from doing the Linux kernel that would be applicable to that task. He could finally be free of the architectural mistakes of his past (e.g. I/O system), not to mention the kernel API.
Real virtualization, now with widespread hardware support, has the potential to revive operating systems research, which seems to have nearly died since Linux became popular. The other obstacle has always been device drivers for enough devices to make a new OS practical. If anyone could rally device driver developers around a standard API in a new VMM, I think it would be Linus. The VMM could provide an I/O API to guest OS's that would abstract devices into a much smaller number of device classes, so that all devices in a class could be run with one device driver in a guest OS.
Realize, that it is US gov't with Keynesian shamanism
Hey, you're the one capitalizing "Free Market" like it's some kind deity.
I just want practical solutions. You don't have any.
- your statement has no meaning. What does this mean 'unimaginable chaos' in this context? What is chaotic about clear cut settings of borders of private property lines?
Nothing, once the lines have been drawn. It's the drawing of the lines that's the problem. Study the history of private property in the U.S. The expansion westward was as chaotic as the government permitted it to be, and the government was fairly permissive at times. So just putting aside the genocide of the native population, you still had local wars between the sheep and cattle ranchers. And then there's things like the California Gold Rush - nothing chaotic about that.
Also watch the series on the how the U.S. national parks came to be. Bottom line: they wouldn't exist without government stepping in and stopping people from turning them into the worst kind of tourist traps. The U.S. has always worked best as a mixed economy. Our problems of late are that the government has been bought, and it seems that will get worse.
So you want to have a "land rush" on the world's oceans? That's just crazy talk. And the exploitation of the oceans that would ensue? The oceans would be dead in ten years. Then what?
There would be no such thing as LIMITED PERSONAL RESPONSIBILITY. It wouldn't exist. All those executives could be sued under this. Responsibility is paramount in the world of business and competition. You cannot take RISK out as a major factor of doing business, and government is busy insuring against all sorts of risks.
Well, if shareholders are going to be liable too (and it seems they ought to be, since they elect the boards of directors, who hire the executives), then I'm going to sell all my stocks. I think if you take a poll, most other stock holders would do the same. The problem here is that the responsibility that shareholders would have is not commensurate with their authority, since corporate elections are majority rule.
It's too risky for you to put money into a bank without you doing due diligence and keeping an eye on what the bank is doing with your money and can't be bothered to put together a meaningful contract as a bank customer? Let's have FDIC.
The U.S. might well have collapsed two years ago without the FDIC. There would have been runs on banks that were completely solvent in the panic that would have developed. The fact of the matter is: most people are just too busy at their jobs to watch what a bank does with their money. In the current climate, I would not trust any bank without FDIC to guarantee my deposits.
For example, if the ocean was owned by a number of private entities, BP wouldn't behave the way they did because:
Ok, let's just ignore the unimaginable chaos implied by your premise, and focus on your conclusion. The fact is that executives in a corporation as large as BP only care about the quarterly and annual results that determine their bonuses. If something really bad happens to BP, they take their winnings and move on to next table. They exist in a global subculture of executives who sit on each other's boards of directors and set each other's salaries. As long as they can escape criminal liability (which apparently wouldn't exist under your system), they'll suffer no long-term consequences for the risks they take.
Now I suppose you could make corporate executives and stock holders personally liable for the damages of their company. I don't think that would work in the long run either, but it would be entertaining to try it for awhile.
Here is the fix (and I am not a lawyer, so this needs to be solidified to fit both the letter and the spirit)
It's ok that you're not a lawyer - lawyers are just code monkeys for the people who make the laws. But what exactly are your qualifications for designing a political/economic system? You can read, and think you understand extremist Libertarian literature?
Here's the deal. The free market is working just fine. Every job that can be outsourced is leaving the country as fast as qualified people can be found in places with a lower cost of living. Jobs that can't be outsourced are more scarce, because fewer people can afford plumbers, electricians, etc. as they've lost their jobs to outsourcing. Industries are consolidating. and laying off unneeded workers. Wealthy people are desperately looking for investments that will make them wealthier, though they'll probably be a little more careful where they put their money until the memory of the last collapse fades.
And here's the end game: many of the jobs that can't be outsourced are going to be done by automation or telepresence before the end of the century. For example, California farmers, noticing which way the wind is blowing on illegal immigration, are getting very serious about replacing those workers with automated machinery. As it happens, automation is going to be much more efficient and economical in the long run. So explain to me again how the "free market" works when most people can't get jobs, and a few plutocrats own the means of production?
Wake up! The "free market" is an abstraction. People are not even close to rational, even with economic decisions. You might as well believe in Santa Claus. You are a prisoner in your own mind. That is the real power of corporations, not the bread and circuses of Washington DC.