No, it's not already possible. The only browser that currently has automatic firefox support is ff 3. That long list of browsers won't work, and ff 2 won't work either.
The OP was referring to MS specifically in that paragraph.
People getting bent out of shape about the address bar is simply absurd.
Thanks for sharing your opinion that other people's opinions are absurd. I think your opinion that our opinion is absurd is absurd. Aren't opinions great?
While I admit, the option to turn it off should appear somewhere, if only in about:config[...]
That's all we're asking for.
the development team isn't ignoring it's users.
Yes they are. Many of us users hate the annoying bar, and they're ignoring our requests to provide a way to get rid of its annoying behavior via about:config.
I have a feeling far more people LIKE the new address bar than dislike it.
I have a feeling that more people want to elect me president than Obama or McCain. Unfortunately I have no hard data to back up my feeling.
I certainly find it very useful at times.
I'm very happy for you. If they would give us a choice, your choice would presumably be to leave it set to the default behavior.
I think I'd go into full cardiac arrest if I ever saw that error message from IE.
I meant that as an example of a javascript message, written by the owner of the web site. The js code detects that you're running IE, and dynamically generates the message.
Not just that, but there needs to be inherent support for inline SVG's into some of the W3 specs.
There is, and has been for a long time. For instance, I have a 2002 O'Reilly book on SVG, and it covers putting SVG inline in XHTML. The only problem is that IE doesn't support XHTML according to w3c standards.
Firefox 3 does support mixed SVG and XHTML. I think the other non-IE browsers do as well.
The problem is that IE is never, ever going to support xhtml. They don't support it now. They don't have plans to support it. Their stated policy is to provide support for it via browser plugins, and even if the user does have a plugin, you can't write a w3c-standard xhtml file that will work. All of this applies to both svg and mathml.
For instance, here's a nearly minimal example of a w3c-standard xhtml file with a little inline mathml:
<?xml version="1.0" encoding="utf-8" ?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1 plus MathML 2.0//EN" "http://www.w3.org/Math/DTD/mathml2/xhtml-math11-f.dtd" > <html xmlns="http://www.w3.org/1999/xhtml"><head><title>foo</title><meta http-equiv="Content-Type" content="application/xhtml+xml; charset=utf-8"/></head><body> <p> testing <math xmlns="http://www.w3.org/1998/Math/MathML"><mrow><msup><mrow><mi>x</mi></mrow><mn>2</mn></msup></mrow></math> </p> </body></html>
This works fine in ff3. (The user doesn't even have to download fonts anymore. If you install ubuntu hardy heron, fire up firefox, and let it look at this page, it will Just Work.) However, if you serve this page up to any version of IE, it will display a file download dialog, which warns that "some files can harm your computer..." It won't render the page.
There is currently no way to write a standards-conformant, static web page with inline mathml so that (1) it renders correctly in firefox, (2) it renders correctly in IE with the MathPlayer plugin, and (3) it doesn't just give a scary dialog box to the ~85% of all users who have IE without the MathPlayer plugin.
Xhtml is basically dead in the water. However, the w3c html 5 standard is going to allow inline mathml and svg as special cases. That is, html 5 won't be xml, and it won't be able to embed other arbitrary types of xml, but it will have all the mathml and svg tags defined in its grammar. Now the real question is whether MS will support those parts of html 5 in IE 10 or whatever. My guess is that they won't, because mathml has no economic value to them, and svg solves a problem that MS wants to solve with Silverlight. However, it's possible that they will end up providing some more graceful degradation of the content, in which case users might start seeing messages like, "Sorry, this page doesn't display in Internet Explorer 10, because Internet Explorer 10 doesn't support SVG. Please use an SVG-enabled browser, such as Firefox, Safari, Opera, Konqueror, or Galeon."
I subscribe to this $3/month hosting since a few months, and the only badness is that about two times so far something "hanged" and I had to contact support so they reboot, and they fixed it within a few hours of notifying with their ticketing system. So I would say that the support is very good, unless its a really critical system when a few-hour outage once a month or two is a problem.
If it's acceptable to you to have your server go down randomly once a month, then that's fine. I would consider it unacceptable. I also wouldn't be willing to pay $3/mo for the privilege of running, say, a web-based word-processor, when I could just install openoffice for free.
I sign up for a webhosting account for, say $40/mo.
Hosting accounts don't cost $40/month any more. You can get a root server (linux-vserver) with 100 GB monthly transfer and 1 GB disk space at star-hosting.de for 24 EUR/year, which is about 38 USD/year ~ 3 USD/month.
Webhosting costs have always depended on how much bandwidth and disk space you need, and on how good you need the reliability and support to be. I've had webhosting at a variety of prices, from $20/month to $100/month. At $100/month, you get horrible reliability and support. As you go down from there, you get more and more horrible reliability and support. If you only need the webhosting for yourself, then maybe you could get by with webhosting as bad as the kind you get for $5/month; but then you're spending $5/month forever, for the sole purpose of continuing to run a certain web app -- and that level of webhosting won't allow you to make your server available to any significant number of other people, which means you won't be able to recoup any of your costs.
Stallman suggests to add a feature to the browser allowing a user to say: "When you get URL X, use the Javascript from URL Y as if it came from URL X." If the user does invoke this feature, he can run his copy of the Javascript and still being able to exchange data with the server hosting the web application.
One big reason this won't work is that a web app consists of two separate pieces of code: one that runs on the server, and one that runs on the client. I wouldn't call it open source if I get to modify 50% of the code, but not the other 50%.
The AGPL already covers this and requires that the source to the server-side code be made available.
Implementing this sounds wildly impractical to me. Suppose I sign up with a service that makes a web app available to to me, and stores my data. At some point I decide I want to modify the behavior of the application by modifying the server-side code. So what do I do now? I sign up for a webhosting account for, say $40/mo. I configure the new server. I migrate all my files. I continue paying $40/mo indefinitely for the new server, and I continue maintaining my forked version of the application forever. Ouch -- this is nothing like the zero-cost, zero-configuration, zero-maintenance setup that was the original lure of the web app. In the world of ordinary open-source apps, the possibility of forking helps to keep users from getting abused or neglected by the developer. If the developer is thinking about changing the license, or making it into adware, or abandoning the software, or making it intro crippleware, or not providing bug fixes, or not making it compatible with new libraries and operating systems --- in all those situations, he knows that if he makes his users too unhappy, someone may fork the software and users may vote with their feet. The barrier to forking is pretty high, and it seldom happens, but the theoretical possibility is always there. In the setup proposed by the article, the barriers to forking are just way too high for it to be a plausible threat. Basically the forker not only has to start maintaining the fork, he also has to start up his own internet-based business to cover his new webhosting costs (or just eat the monthly cost of webhosting for the sole purpose of continuing to be able to run this one app).
Well, first off, with an open infrastructure, that service could be run on YOUR server, in which case, you pay your own bills.
The problem with this solution is that it eliminates some of the main reasons that people are interested in web apps. One reason is that you don't need to do any work to set up and maintain an application on your own computer. For the typical user, setting up a service on a server is significantly more difficult than just installing an app on their own machine. For organizations, the allure of web apps is that they don't need to maintain a complicated IT infrastructure just to let their workers get their work done; requiring them to set up yet another server-side app is a step in the wrong direction. Another reason web apps are attractive to a lot of people is the possibility of getting seamless upgrades; that advantage goes away if you have to run the software on your own server, and upgrade it yourself. Yet anothe reason people like web apps is that they're free as in beer; that goes away if you have to pay to host it on your own server.
You can set up a funding scheme with where the application doesn't keep user information. For example, you could have a third-party subscription broker that generates cryptographic tokens that indicate you paid for service. It's like buying ride tickets an amusement part; none of the individual ride operators needs to know (or care) anything about your billing information.
I think there are some big practical barriers to making this happen. For instance, suppose I'm going to subscribe to such a service, and it's going to cost me $5/month to store my data. In this kind of system, I need to keep a record of my cryptographic key, and at the end of every month when I access my data, I'm presumably going to get a message saying, "Your rental fee for the month is about to expire. Please fill out this form in order to keep your data from evaporating." Lots of problems here: (1) Users generally don't like filling in the same address and credit card info over and over. That's why every big online retailer encourages users to set up permanent accounts. If you really want anonymous online payments to be convenient and popular, you need a whole new infrastructure for internet-based anonymous payments, and that infrastructure doesn't exist. (2) What if I go on vacation and forget to renew my account? Oops, now all my data's been erased. They can't send me a warning, because they don't have my address. (3) What if I lose my cryptographic key? Since they don't store any identifying information about me, there's no way for them to verify my identity in order to let me change my password. (4) There's a strong incentive for online businesses to collect the maximum amount of information about their users (which is why they fight tooth and nail against privacy laws), and an overpowering economic incentive to get their users to set up recurring credit card charges for any service that requires maintaining continuing resources for them in a data center (which is why it's often virtually impossible to cancel service without changing your credit card to a new number).
Before we even start worrying about privacy with respect to web apps, we have to worry about making web apps work within the existing technical constraints. There are serious technical problems with adapting the browser and the web to make web apps. Try google's web-app office suite, for example. It implements a tiny fraction of the functionality of a traditional word processor and spreadsheet, and its performance is just plain unacceptable, especially in the spreadsheet. Http, the browser, javascript, and w3c standards simply were not designed for this type of task, and it's not at all clear that they can be adapted to it. That means that if we ever do get something like the experience they're talking about in the article, it will probably be based on an entirely different design, and it's going to be hard to work out the privacy issues without knowing the technical and financial implications of that new design.
The paradigm they're talking about is one in which users get a service from someone running a rack full of servers. For instance, if I write a letter in my web-app word-processor, somewhere there's got to be a server that's storing my document. The person running the service needs to pay their elecric bill. How are they going to do it? Well, they could make their users look at ads, but that won't work if the app is really user-modifiable, because someone will come out with a version that doesn't show the ads. They could charge the user a monthly fee, but that won't work, because the article proposes to set up the service so that the provider knows absolutely nothing about the user, not even his username.
Stallman suggests to add a feature to the browser allowing a user to say: "When you get URL X, use the Javascript from URL Y as if it came from URL X." If the user does invoke this feature, he can run his copy of the Javascript and still being able to exchange data with the server hosting the web application.
One big reason this won't work is that a web app consists of two separate pieces of code: one that runs on the server, and one that runs on the client. I wouldn't call it open source if I get to modify 50% of the code, but not the other 50%. Another problem is that part of the allure of web apps is that they require zero configuration, and can be invisibly upgraded at any time. It's hard to see how you'd maintain that benefit while having users run a forked version of the client-side code. What happens when the provider wants to modify the server-side code in a way that breaks compatibility with the forked client-side code?
The wise answer is "maybe". There are only two companies that have done something similar. Apple, tried doing it from scratch and basically killed itself in the process, had to adapt already written NeXT. Even that took forever and sucked for a couple of years before they got everything right. Microsoft did some
thing similar with windows NT: a ground up modern rewrite that was mostly compatible with the existing windows
It may be dangerous to reason by historical analogy, because the hardware situation is qualitatively different now. CPUs are no longer showing the kind of Moore's-law growth in power that they used to. Meanwhile ram and hard disks are ridiculously cheap. For the typical user who just uses a computer for websurfing, email, and word-processing, it's kind of silly to spend any significant amount of money on a new system. They already have more ram and disk space than they need, and the CPU isn't going to be that much faster. We're seeing perfectly reasonable desktop hardware now for $200, and it won't be long until you can get that same hardware for $50.
If I was one of the people at the helm of Microsoft, I'd be really worried about this, because when the hardware is $50, there's not going to be much room left for profit on the OS. Most retailers have been reluctant to sell cheap hardware, because their own margins on it are thin, but it's just a matter of time until that changes. Fry's sold $200 Great-Quality-brand machines for years, and WalMart is now selling the gPC online for $200. Once people realize that they can get a computer for $100, or $50, the dam is going to have to break, and retailers are no longer going to be able to sell machines at prices of $500 or $1000. It's going to be like the transition from the radio as a big wooden box to the transistor radio that you could carry with you to the beach, and throw in a dumpster if it got sand and water in it.
In this new landscape, there's very little reason for MS to exist. One of the few reasons left for them to exist is that people have money invested in software, and they don't want to have to buy new software. The insane success of the eeePC -- and even at much higher prices than they originally thought they could get --- shows how vulnerable MS is. There are a lot of users out there who just use their computers for word-processing, email, and websurfing. Maybe first they buy a $50 Linux box for their kid to use to write her high school papers. That works out okay, and pretty soon the kid is like, "Mom, are you crazy? You're talking about spending $400 for a new computer? Just buy one like mine."
The Ars Technica piece is interesting, but I'm pretty skeptical about this whole idea of making radical changes in Windows and breaking backward-compatibility.
One thing you have to keep in mind is that there's a huge downside for the user when you break backward-compatibility. Apple actually did an amazing job of maintaining backward-compatibility when they made the switch from 68000 to powerpc, but when they brought out MacOS X, the backward compatibility was lousy. You could still run classic apps on X, but they typically worked very poorly -- some features wouldn't work, apps would crash, and it took a really long time to start up the classic environment. Essentially Apple expected you to buy all new applications. Then Apple kept on bringing out frequent point-upgrades to MacOS X, and every single one cost a significant amount of money. My wife bought one of the early lamp-shaped iMacs, and we stayed on the upgrade treadmill for a while, but it really got old spending money every six months or so for a new version of the OS, so at this point we're still running an old version of MacOS on that (expensive) machine. Now we basically can't run any new software, because it only works on newer versions of MacOS X.
It's also worth looking at it from MS's point of view. They're a monopoly, and their interest is in keeping users sucking at the tit. Maintaining backward compatibility has worked very well for them. One of the main things keeping Windows users from jumping ship for another OS is that they know their apps will continue to work. It's actually kind of amazing. I tech at a community college, and some of my colleagues are still using an old DOS shareware planetarium app. It still runs on Windows XP.
No, that's incorrect. In space travel, the vehicle is in some orbit, and in the absence of a force other than gravity, it's just going to continue in that (typically elliptical) orbit forever. Say you're going to Mars, for instance. You needed to match orbits with Mars, which means you're in the same nearly circualr orbit around the sun that Mars is in. (Of course you also have to insert yourself into orbit around Mars, and get yourself out of that orbit as well, but let's not worry about that for now.) Once you're ready to leave, you don't just wait for the sun's gravity to pull you downhill back to Earth. You're in a circular orbit whose radius is greater than that of the Earth's orbit, so you're not coming back toward the sun unless you can reduce your velocity.
To understand how you'd really use a solar sail, let's start with the case where you just want to increase your distance from the sun. Intuitively, you'd think that you'd just orient the sail perpendicular to the sun's rays, and let it thrust you outward. However, that doesn't work, because the thrust from the sunlight is orders of magnitude less than the sun's gravitational force. Doing that would be sort of like dialing down the strength of the sun's gravity by some tiny percentage, which would alter your orbit for a given velocity vector, but only by a tiny amount.
What you actually do is to point your sail at an angle. The sunlight's thrust then has both a radial component and a tangential component. The tangential component does mechanical work, because it operates in the same direction as the motion of the vehicle. That means it increases the vehicle's kinetic energy. The higher-energy orbit takes you farther out away from the sun.
When you want to come back, you do something similar, but you tilt the sail the opposite way. The tangential component is now in the opposite direction compared to your motion, so it does negative work, reducing your kinetic energy.
This web page has an example that calculates the optimal angle to tilt the sail at.
IMO the changes proposed for js 2 aren't very exciting. The biggest problems with js aren't really problems with the language design, they're problems with the lack of standardization in the interface to the browser. I don't see the burning need to make js more oo, more statically typed, or more like java.
What I think really will be cool is the synergy between js and html 5. Html 5 has lots of good features for doing web apps, including audio, persistent storage, and graphics (canvas, inline svg without xhtml). Most of this is stuff you could have done before using java applets or flash, but now you'll be able to do them using a w3c standard that the vast majority of users will probably end up actually having supported in their browsers.
Thanks! Hmm...actually, now that I think of it, I guess what I really want isn't what you described. I probably want all scripts to be blocked by default, I want to be notified when 1st-party scripts are blocked, and I don't want to be notified when 3rd-party scripts are blocked. I guess the default behavior isn't so bad; I just have to make a habit of specifically blacklisting 3rd-party sites and specifically whitelisting 1st-party sites, and once I've done that once, I won't get the annoying alerts every time I visit a particular site.
Set it to allow first party scripts and block 3rd party scripts. 99.44% of all ads are GONE, and browser performance will greatly enhanced.
Where is the setting for this in NoScript's preferences gui? The behavior you're describing is exactly what I want, but I've been through every tab twice, and I can't see anything that looks like it does that.
Keep in mind that ruby and PHP are essentially contemporaries - they've both been in real use for over a decade. By most measures, one would think of them as being "mature" technologies, and yet we still see bugs like this crop up in both languages. I think it just goes to show - while selecting a "mature" technology has its advantages, it will not make you immune to problems.
I'd interpret the same facts the other way around. A decade isn't very long for a programming language to mature. Ruby and PHP have both only been around for a decade, so they're not very mature. I do most of my coding in perl, but have done one significant project in ruby, and I can see some advantages and disadvantages of each. If you really like OOP, and/or you have a project that's naturally well suited to the OOP approach, then perl is an extremely awkward language, and ruby is much more natural. However, perl is 21 years old, and the perl 5 implementation is extremely mature. You simply don't run into the kind of implementation bugs in perl that you do in ruby. As a concrete example, my ruby project does a lot of string munging, and I had to choose between using ruby 1.9 in order to get a regex engine that was as full-featured as perl's, or using ruby 1.8. I chose 1.9, and after the project was complete and working well, I started running into cases where the interpreter's regex engine would crash the interpreter. You could say it's my own darn fault for choosing a beta version of the language, but with a more mature language I wouldn't have had to make a choice like that between features and stability. I've also had ruby code break because of changes in the design of the language, and that has never, ever happened to me with perl. (And before anyone starts up about how perl 6 will break everyone's code, no, it won't. Perl 6 will run perl 5 code in compatibility mode.)
Generally speaking, if you already have on-site utility power, that's going to be cheaper over the long run than solar cells.
I know you prefaced this with "generally speaking," but this statement is way too broad to be useful. It depends on what latitude you live at; which way your roof faces; whether you have trees giving partial shade on your roof at some times of day and year; how much the government is subsidizing you; how much electricity costs today in your area (which varies a huge amount from place to place); and how much you think electricity is going to cost over the 25-year life of the system.
For your shed, presumably the reason you're thinking of solar is because you don't have AC wiring going out to it, which means you're talking about a non-grid-tied system. This raises some issues. (1) Running wiring from your house out to the shed is probably much cheaper and easier than doing solar and getting 110 V AC just in the shed. (2) A non-grid-tied system is actually a more complex, expensive, and and difficult project than a grid-tied system. You'd need a battery and a charging system. The battery is big, needs maintenance, doesn't have a long design lifetime, and can be dangerous as hell if you screw up.
You also don't state your requirements. How much power do you need? Do you need AC, or can you get by with DC? DC is safer, and also doesn't require an inverter. Getting rid of the inverter means your efficiency is higher, and it also cuts the cost of the system. A classic application for DC solar is a pool pump. Pool pumps use DC motors, so it's wasteful to use an inverter to convert to AC, and then rectify it back to DC for the pump again. I would imagine that if all you want is lighting, you can probably do 12 V DC without an inverter.
good thing for Microsoft that Gary Kildall was out flying his airplane when IBM came by.
I worked as a summer intern at Digital Research ca. 1982, and heard the story about the airplane. However, a lot of other stories have been floating around. Wikipedia has a fairly thoroughly sourced account of the incident, and it sounds like the real situation was significantly different from the classic story that I heard and that you're repeating.
I was all set to reply to your post by pointing out that PS/2 keyboards are $4, while USB keyboards are $60 or something. Then I checked at frys.com, and found USB keyboards for $10. I hadn't realized USB prices had come down so much. Still, a lot of individuals and businesses have huge piles of PS/2 keyboards sitting around that they'd like to be able to keep on using.
Don't underestimate package management - it is critical. It is the main differentiator between distros and it is the key to Ubuntu's current success. It's also one of the main reasons that Linux is so much more stable than Windows.
To amplify a little on what you said, what matters for desktop use is:
how well the packaging system works (taking care of dependencies automatically, etc.)
the quality of the packages (e.g., making sure you don't get a situation where application A needs version 3.4 of a certain library and won't run with 3.5, while application B needs 3.5 and won't work with 3.4)
the variety of desktop apps available
convenience of being able to find packages without lots of hunting around on web sites
up to date desktop apps
My experience with desktop use has been:
Ubuntu does all five of these things well
FreeBSD did 1, 4, and 5 well.
Red Hat did none of these things well.
Vanilla Debian does 1, 2, 3, and 4 well.
I only tried SUSE briefly, but I definitely remember that it didn't seem to do 4 well. There was no central repository, so you basically had to websurf and ask around to find web sites that were good, well-maintained sources of packages.
And before twenty people jump down my throat screaming that one of these distros really does all the things I'm talking about, please note the word "well." For example, FreeBSD's ports and packages are intended to do 2 well; it's just that in my experience there were many cases where it failed, probably because there just aren't that many people spending as many hours on packaging desktop apps for FreeBSD as there are for Ubuntu. Also note that I'm only commenting on the desktop here. E.g., I run vanilla Debian now on my server, and I like it just fine.
I think the confusion may have arisen because the name is misleading. If you set it, it will still match titles and bookmarks (which you didn't type), but it will no longer match urls that you didn't type (which makes it behave less like the old firefox).
You're incorrect about browser.urlbar.matchOnlyTyped. It makes the behavior *less* like the old behavior. If you set this flag, then it will no longer match urls that you didn't type (which is different from the old behavior), but it will still match titles and bookmarks (which is different from the old behavior).
I was left with a several questions that weren't addressed by the article.
The slashdot summary says the article explains how pages are selected for archiving, but I couldn't find anything in the article that explicitly explained that. It does say that the actual crawler is run by alexa, which hands off the data to them, but it didn't say what the criteria were. Alexa computes various stats about web sites, so presumably they could apply some kind of minimum cut. Or do they try to index every single lame personal page, unless the owner opts out? That seems like it would require an unreasonable amount of disk space. The web also has a lot of stuff like, e.g., the kind of spam sites that try to scam google's search/ad system; I wonder if the archive records those.
The article didn't say a darn thing about funding. They have to run thousands of machines, so the electric bills must be formidable. Where the heck do they get their money? Is there a significant chance that their funding will dry up at some point in the future, and the whole archive will disappear?
The article states that they moved from plain Debian to Ubuntu. That surprised me, and I was curious why they'd do that. E.g., if you're shopping for webhosts, it's much more common for them to offer plain Debian than Ubuntu. I love Ubuntu as a desktop distro, but it surprises me that they'd see any big advantage in using Ubuntu for their application.
Slashdot Mirror
No, it's not already possible. The only browser that currently has automatic firefox support is ff 3. That long list of browsers won't work, and ff 2 won't work either.
I'm the OP, and I wasn't.
Thanks for sharing your opinion that other people's opinions are absurd. I think your opinion that our opinion is absurd is absurd. Aren't opinions great?
That's all we're asking for.
Yes they are. Many of us users hate the annoying bar, and they're ignoring our requests to provide a way to get rid of its annoying behavior via about:config.
I have a feeling that more people want to elect me president than Obama or McCain. Unfortunately I have no hard data to back up my feeling.
I'm very happy for you. If they would give us a choice, your choice would presumably be to leave it set to the default behavior.
I think I'd go into full cardiac arrest if I ever saw that error message from IE.
I meant that as an example of a javascript message, written by the owner of the web site. The js code detects that you're running IE, and dynamically generates the message.
There is, and has been for a long time. For instance, I have a 2002 O'Reilly book on SVG, and it covers putting SVG inline in XHTML. The only problem is that IE doesn't support XHTML according to w3c standards.
The problem is that IE is never, ever going to support xhtml. They don't support it now. They don't have plans to support it. Their stated policy is to provide support for it via browser plugins, and even if the user does have a plugin, you can't write a w3c-standard xhtml file that will work. All of this applies to both svg and mathml.
For instance, here's a nearly minimal example of a w3c-standard xhtml file with a little inline mathml:
This works fine in ff3. (The user doesn't even have to download fonts anymore. If you install ubuntu hardy heron, fire up firefox, and let it look at this page, it will Just Work.) However, if you serve this page up to any version of IE, it will display a file download dialog, which warns that "some files can harm your computer..." It won't render the page.
There is currently no way to write a standards-conformant, static web page with inline mathml so that (1) it renders correctly in firefox, (2) it renders correctly in IE with the MathPlayer plugin, and (3) it doesn't just give a scary dialog box to the ~85% of all users who have IE without the MathPlayer plugin.
Xhtml is basically dead in the water. However, the w3c html 5 standard is going to allow inline mathml and svg as special cases. That is, html 5 won't be xml, and it won't be able to embed other arbitrary types of xml, but it will have all the mathml and svg tags defined in its grammar. Now the real question is whether MS will support those parts of html 5 in IE 10 or whatever. My guess is that they won't, because mathml has no economic value to them, and svg solves a problem that MS wants to solve with Silverlight. However, it's possible that they will end up providing some more graceful degradation of the content, in which case users might start seeing messages like, "Sorry, this page doesn't display in Internet Explorer 10, because Internet Explorer 10 doesn't support SVG. Please use an SVG-enabled browser, such as Firefox, Safari, Opera, Konqueror, or Galeon."
I subscribe to this $3/month hosting since a few months, and the only badness is that about two times so far something "hanged" and I had to contact support so they reboot, and they fixed it within a few hours of notifying with their ticketing system. So I would say that the support is very good, unless its a really critical system when a few-hour outage once a month or two is a problem.
If it's acceptable to you to have your server go down randomly once a month, then that's fine. I would consider it unacceptable. I also wouldn't be willing to pay $3/mo for the privilege of running, say, a web-based word-processor, when I could just install openoffice for free.
Webhosting costs have always depended on how much bandwidth and disk space you need, and on how good you need the reliability and support to be. I've had webhosting at a variety of prices, from $20/month to $100/month. At $100/month, you get horrible reliability and support. As you go down from there, you get more and more horrible reliability and support. If you only need the webhosting for yourself, then maybe you could get by with webhosting as bad as the kind you get for $5/month; but then you're spending $5/month forever, for the sole purpose of continuing to run a certain web app -- and that level of webhosting won't allow you to make your server available to any significant number of other people, which means you won't be able to recoup any of your costs.
Implementing this sounds wildly impractical to me. Suppose I sign up with a service that makes a web app available to to me, and stores my data. At some point I decide I want to modify the behavior of the application by modifying the server-side code. So what do I do now? I sign up for a webhosting account for, say $40/mo. I configure the new server. I migrate all my files. I continue paying $40/mo indefinitely for the new server, and I continue maintaining my forked version of the application forever. Ouch -- this is nothing like the zero-cost, zero-configuration, zero-maintenance setup that was the original lure of the web app. In the world of ordinary open-source apps, the possibility of forking helps to keep users from getting abused or neglected by the developer. If the developer is thinking about changing the license, or making it into adware, or abandoning the software, or making it intro crippleware, or not providing bug fixes, or not making it compatible with new libraries and operating systems --- in all those situations, he knows that if he makes his users too unhappy, someone may fork the software and users may vote with their feet. The barrier to forking is pretty high, and it seldom happens, but the theoretical possibility is always there. In the setup proposed by the article, the barriers to forking are just way too high for it to be a plausible threat. Basically the forker not only has to start maintaining the fork, he also has to start up his own internet-based business to cover his new webhosting costs (or just eat the monthly cost of webhosting for the sole purpose of continuing to be able to run this one app).
The problem with this solution is that it eliminates some of the main reasons that people are interested in web apps. One reason is that you don't need to do any work to set up and maintain an application on your own computer. For the typical user, setting up a service on a server is significantly more difficult than just installing an app on their own machine. For organizations, the allure of web apps is that they don't need to maintain a complicated IT infrastructure just to let their workers get their work done; requiring them to set up yet another server-side app is a step in the wrong direction. Another reason web apps are attractive to a lot of people is the possibility of getting seamless upgrades; that advantage goes away if you have to run the software on your own server, and upgrade it yourself. Yet anothe reason people like web apps is that they're free as in beer; that goes away if you have to pay to host it on your own server.
I think there are some big practical barriers to making this happen. For instance, suppose I'm going to subscribe to such a service, and it's going to cost me $5/month to store my data. In this kind of system, I need to keep a record of my cryptographic key, and at the end of every month when I access my data, I'm presumably going to get a message saying, "Your rental fee for the month is about to expire. Please fill out this form in order to keep your data from evaporating." Lots of problems here: (1) Users generally don't like filling in the same address and credit card info over and over. That's why every big online retailer encourages users to set up permanent accounts. If you really want anonymous online payments to be convenient and popular, you need a whole new infrastructure for internet-based anonymous payments, and that infrastructure doesn't exist. (2) What if I go on vacation and forget to renew my account? Oops, now all my data's been erased. They can't send me a warning, because they don't have my address. (3) What if I lose my cryptographic key? Since they don't store any identifying information about me, there's no way for them to verify my identity in order to let me change my password. (4) There's a strong incentive for online businesses to collect the maximum amount of information about their users (which is why they fight tooth and nail against privacy laws), and an overpowering economic incentive to get their users to set up recurring credit card charges for any service that requires maintaining continuing resources for them in a data center (which is why it's often virtually impossible to cancel service without changing your credit card to a new number).
There are a lot of problems with this proposal.
Before we even start worrying about privacy with respect to web apps, we have to worry about making web apps work within the existing technical constraints. There are serious technical problems with adapting the browser and the web to make web apps. Try google's web-app office suite, for example. It implements a tiny fraction of the functionality of a traditional word processor and spreadsheet, and its performance is just plain unacceptable, especially in the spreadsheet. Http, the browser, javascript, and w3c standards simply were not designed for this type of task, and it's not at all clear that they can be adapted to it. That means that if we ever do get something like the experience they're talking about in the article, it will probably be based on an entirely different design, and it's going to be hard to work out the privacy issues without knowing the technical and financial implications of that new design.
The paradigm they're talking about is one in which users get a service from someone running a rack full of servers. For instance, if I write a letter in my web-app word-processor, somewhere there's got to be a server that's storing my document. The person running the service needs to pay their elecric bill. How are they going to do it? Well, they could make their users look at ads, but that won't work if the app is really user-modifiable, because someone will come out with a version that doesn't show the ads. They could charge the user a monthly fee, but that won't work, because the article proposes to set up the service so that the provider knows absolutely nothing about the user, not even his username.
One big reason this won't work is that a web app consists of two separate pieces of code: one that runs on the server, and one that runs on the client. I wouldn't call it open source if I get to modify 50% of the code, but not the other 50%. Another problem is that part of the allure of web apps is that they require zero configuration, and can be invisibly upgraded at any time. It's hard to see how you'd maintain that benefit while having users run a forked version of the client-side code. What happens when the provider wants to modify the server-side code in a way that breaks compatibility with the forked client-side code?
It may be dangerous to reason by historical analogy, because the hardware situation is qualitatively different now. CPUs are no longer showing the kind of Moore's-law growth in power that they used to. Meanwhile ram and hard disks are ridiculously cheap. For the typical user who just uses a computer for websurfing, email, and word-processing, it's kind of silly to spend any significant amount of money on a new system. They already have more ram and disk space than they need, and the CPU isn't going to be that much faster. We're seeing perfectly reasonable desktop hardware now for $200, and it won't be long until you can get that same hardware for $50.
If I was one of the people at the helm of Microsoft, I'd be really worried about this, because when the hardware is $50, there's not going to be much room left for profit on the OS. Most retailers have been reluctant to sell cheap hardware, because their own margins on it are thin, but it's just a matter of time until that changes. Fry's sold $200 Great-Quality-brand machines for years, and WalMart is now selling the gPC online for $200. Once people realize that they can get a computer for $100, or $50, the dam is going to have to break, and retailers are no longer going to be able to sell machines at prices of $500 or $1000. It's going to be like the transition from the radio as a big wooden box to the transistor radio that you could carry with you to the beach, and throw in a dumpster if it got sand and water in it.
In this new landscape, there's very little reason for MS to exist. One of the few reasons left for them to exist is that people have money invested in software, and they don't want to have to buy new software. The insane success of the eeePC -- and even at much higher prices than they originally thought they could get --- shows how vulnerable MS is. There are a lot of users out there who just use their computers for word-processing, email, and websurfing. Maybe first they buy a $50 Linux box for their kid to use to write her high school papers. That works out okay, and pretty soon the kid is like, "Mom, are you crazy? You're talking about spending $400 for a new computer? Just buy one like mine."
The Ars Technica piece is interesting, but I'm pretty skeptical about this whole idea of making radical changes in Windows and breaking backward-compatibility.
One thing you have to keep in mind is that there's a huge downside for the user when you break backward-compatibility. Apple actually did an amazing job of maintaining backward-compatibility when they made the switch from 68000 to powerpc, but when they brought out MacOS X, the backward compatibility was lousy. You could still run classic apps on X, but they typically worked very poorly -- some features wouldn't work, apps would crash, and it took a really long time to start up the classic environment. Essentially Apple expected you to buy all new applications. Then Apple kept on bringing out frequent point-upgrades to MacOS X, and every single one cost a significant amount of money. My wife bought one of the early lamp-shaped iMacs, and we stayed on the upgrade treadmill for a while, but it really got old spending money every six months or so for a new version of the OS, so at this point we're still running an old version of MacOS on that (expensive) machine. Now we basically can't run any new software, because it only works on newer versions of MacOS X.
It's also worth looking at it from MS's point of view. They're a monopoly, and their interest is in keeping users sucking at the tit. Maintaining backward compatibility has worked very well for them. One of the main things keeping Windows users from jumping ship for another OS is that they know their apps will continue to work. It's actually kind of amazing. I tech at a community college, and some of my colleagues are still using an old DOS shareware planetarium app. It still runs on Windows XP.
No, that's incorrect. In space travel, the vehicle is in some orbit, and in the absence of a force other than gravity, it's just going to continue in that (typically elliptical) orbit forever. Say you're going to Mars, for instance. You needed to match orbits with Mars, which means you're in the same nearly circualr orbit around the sun that Mars is in. (Of course you also have to insert yourself into orbit around Mars, and get yourself out of that orbit as well, but let's not worry about that for now.) Once you're ready to leave, you don't just wait for the sun's gravity to pull you downhill back to Earth. You're in a circular orbit whose radius is greater than that of the Earth's orbit, so you're not coming back toward the sun unless you can reduce your velocity.
To understand how you'd really use a solar sail, let's start with the case where you just want to increase your distance from the sun. Intuitively, you'd think that you'd just orient the sail perpendicular to the sun's rays, and let it thrust you outward. However, that doesn't work, because the thrust from the sunlight is orders of magnitude less than the sun's gravitational force. Doing that would be sort of like dialing down the strength of the sun's gravity by some tiny percentage, which would alter your orbit for a given velocity vector, but only by a tiny amount.
What you actually do is to point your sail at an angle. The sunlight's thrust then has both a radial component and a tangential component. The tangential component does mechanical work, because it operates in the same direction as the motion of the vehicle. That means it increases the vehicle's kinetic energy. The higher-energy orbit takes you farther out away from the sun.
When you want to come back, you do something similar, but you tilt the sail the opposite way. The tangential component is now in the opposite direction compared to your motion, so it does negative work, reducing your kinetic energy.
This web page has an example that calculates the optimal angle to tilt the sail at.
IMO the changes proposed for js 2 aren't very exciting. The biggest problems with js aren't really problems with the language design, they're problems with the lack of standardization in the interface to the browser. I don't see the burning need to make js more oo, more statically typed, or more like java.
What I think really will be cool is the synergy between js and html 5. Html 5 has lots of good features for doing web apps, including audio, persistent storage, and graphics (canvas, inline svg without xhtml). Most of this is stuff you could have done before using java applets or flash, but now you'll be able to do them using a w3c standard that the vast majority of users will probably end up actually having supported in their browsers.
Thanks! Hmm...actually, now that I think of it, I guess what I really want isn't what you described. I probably want all scripts to be blocked by default, I want to be notified when 1st-party scripts are blocked, and I don't want to be notified when 3rd-party scripts are blocked. I guess the default behavior isn't so bad; I just have to make a habit of specifically blacklisting 3rd-party sites and specifically whitelisting 1st-party sites, and once I've done that once, I won't get the annoying alerts every time I visit a particular site.
Where is the setting for this in NoScript's preferences gui? The behavior you're describing is exactly what I want, but I've been through every tab twice, and I can't see anything that looks like it does that.
I'd interpret the same facts the other way around. A decade isn't very long for a programming language to mature. Ruby and PHP have both only been around for a decade, so they're not very mature. I do most of my coding in perl, but have done one significant project in ruby, and I can see some advantages and disadvantages of each. If you really like OOP, and/or you have a project that's naturally well suited to the OOP approach, then perl is an extremely awkward language, and ruby is much more natural. However, perl is 21 years old, and the perl 5 implementation is extremely mature. You simply don't run into the kind of implementation bugs in perl that you do in ruby. As a concrete example, my ruby project does a lot of string munging, and I had to choose between using ruby 1.9 in order to get a regex engine that was as full-featured as perl's, or using ruby 1.8. I chose 1.9, and after the project was complete and working well, I started running into cases where the interpreter's regex engine would crash the interpreter. You could say it's my own darn fault for choosing a beta version of the language, but with a more mature language I wouldn't have had to make a choice like that between features and stability. I've also had ruby code break because of changes in the design of the language, and that has never, ever happened to me with perl. (And before anyone starts up about how perl 6 will break everyone's code, no, it won't. Perl 6 will run perl 5 code in compatibility mode.)
For your shed, presumably the reason you're thinking of solar is because you don't have AC wiring going out to it, which means you're talking about a non-grid-tied system. This raises some issues. (1) Running wiring from your house out to the shed is probably much cheaper and easier than doing solar and getting 110 V AC just in the shed. (2) A non-grid-tied system is actually a more complex, expensive, and and difficult project than a grid-tied system. You'd need a battery and a charging system. The battery is big, needs maintenance, doesn't have a long design lifetime, and can be dangerous as hell if you screw up.
You also don't state your requirements. How much power do you need? Do you need AC, or can you get by with DC? DC is safer, and also doesn't require an inverter. Getting rid of the inverter means your efficiency is higher, and it also cuts the cost of the system. A classic application for DC solar is a pool pump. Pool pumps use DC motors, so it's wasteful to use an inverter to convert to AC, and then rectify it back to DC for the pump again. I would imagine that if all you want is lighting, you can probably do 12 V DC without an inverter.
good thing for Microsoft that Gary Kildall was out flying his airplane when IBM came by.
I worked as a summer intern at Digital Research ca. 1982, and heard the story about the airplane. However, a lot of other stories have been floating around. Wikipedia has a fairly thoroughly sourced account of the incident, and it sounds like the real situation was significantly different from the classic story that I heard and that you're repeating.
I was all set to reply to your post by pointing out that PS/2 keyboards are $4, while USB keyboards are $60 or something. Then I checked at frys.com, and found USB keyboards for $10. I hadn't realized USB prices had come down so much. Still, a lot of individuals and businesses have huge piles of PS/2 keyboards sitting around that they'd like to be able to keep on using.
To amplify a little on what you said, what matters for desktop use is:
My experience with desktop use has been:
And before twenty people jump down my throat screaming that one of these distros really does all the things I'm talking about, please note the word "well." For example, FreeBSD's ports and packages are intended to do 2 well; it's just that in my experience there were many cases where it failed, probably because there just aren't that many people spending as many hours on packaging desktop apps for FreeBSD as there are for Ubuntu. Also note that I'm only commenting on the desktop here. E.g., I run vanilla Debian now on my server, and I like it just fine.
I think the confusion may have arisen because the name is misleading. If you set it, it will still match titles and bookmarks (which you didn't type), but it will no longer match urls that you didn't type (which makes it behave less like the old firefox).
You're incorrect about browser.urlbar.matchOnlyTyped. It makes the behavior *less* like the old behavior. If you set this flag, then it will no longer match urls that you didn't type (which is different from the old behavior), but it will still match titles and bookmarks (which is different from the old behavior).
I was left with a several questions that weren't addressed by the article.
The slashdot summary says the article explains how pages are selected for archiving, but I couldn't find anything in the article that explicitly explained that. It does say that the actual crawler is run by alexa, which hands off the data to them, but it didn't say what the criteria were. Alexa computes various stats about web sites, so presumably they could apply some kind of minimum cut. Or do they try to index every single lame personal page, unless the owner opts out? That seems like it would require an unreasonable amount of disk space. The web also has a lot of stuff like, e.g., the kind of spam sites that try to scam google's search/ad system; I wonder if the archive records those.
The article didn't say a darn thing about funding. They have to run thousands of machines, so the electric bills must be formidable. Where the heck do they get their money? Is there a significant chance that their funding will dry up at some point in the future, and the whole archive will disappear?
The article states that they moved from plain Debian to Ubuntu. That surprised me, and I was curious why they'd do that. E.g., if you're shopping for webhosts, it's much more common for them to offer plain Debian than Ubuntu. I love Ubuntu as a desktop distro, but it surprises me that they'd see any big advantage in using Ubuntu for their application.