Slashdot Mirror
Mozilla Tries New "Lorentz" Dev Model
With the recent release of Firefox 3.6, Mozilla has also decided to try out a new development model dubbed "Lorentz." A blend of both Agile and more traditional "waterfall" development models, the new methodology aims to deliver new features much more quickly while still maintaining backwards compatibility, security, and overall quality. Only time will tell if this is effective, or just another management fad. "If the new approach sounds familiar, that's because Unix and Linux development has attempted similar kinds of release variations for iterating new features while maintaining backwards compatibility. HP-UX, for example, is currently on its HP-UX 11iv3 release, which receives updates several times a year that add incremental new functionality. The Linux 2.6.x kernel gets new releases approximately every three months, which include new features as well."
Is this chaotic release schedule supposed to be more attractive?
-V-
Who can decide a priori? Nobody.
-Sartre
Can I use the theory of special relativity to get out of missed deadlines? Sure, we are way behind in this frame of reference. But as viewed from a different frame of reference traveling near the speed of light relative to us we shipped yesterday!
God forbids if a name should suggest something of substance.
Fuck systemd. Fuck Redhat. Fuck Soylent, too. Wait, scratch the last one.
with lean methods?
Where have I heard this before?
Best Slashdot Co
What's wrong is the absence of 2.7.* where the new features we're getting in the "stable" kernel should have stayed until they were stable.
All of the Firefox branches are named after national parks... the name has nothing to do with the development model.
http://en.wikipedia.org/wiki/Lorentz_National_Park
Management has dubbed the new scheme - Lorentz of Arabia!
Thank you, thank you, I'll be here all week! Try the lamb!
[UID-HeinzIntel]
Plus, with the "Lorentz" transformation, time dilation makes it a lot easier to hit release dates. But there has been some concern over the developers' sudden weight gain.
the new methodology aims to deliver new features much more quickly while still maintaining backwards compatibility, security, and overall quality.
A style of management is only as good as its manager(s). We've had many, many methods of improving all three of those but as an industry we routinely and repeatedly turn it down for most applications over cost considerations. A new hybrid model of development won't change this -- continual pressure from inside the organization will eventually subvert any gains at the process level. Senior level management has to push this from the start -- only then would this or any other kind of methodology have a chance at achieving its goals.
#fuckbeta #iamslashdot #dicemustdie
At Yahoo! we tried this on a few projects and ended up calling it waterscrum. Wanting the dev flexibility of agile and the (perceived) business certainty of waterfall at the same time isn't really possible when it's not understood that the dev methodology has impacts outside of the tech organization. If you're doing agile dev, the marketing materials, sales collateral, etc are much more difficult to write and lock down when you're looking to make a splash in the market. For agile to work the entire company needs to be okay with some level of uncertainty, or at least understand that for major market releases you still need to plan a date far in advance. Just because you're launching code doesn't mean you're launching a product, and getting materials locked down is harder to do when, by definition, changes happen more frequently.
And there was me thinking it was named after EVE T1 salvagable materials ... looking foward to the "Burned Logic Circuit" version ... oh, wait, maybe we've already had that one, it makes your RAM fry from overuse.
Mozilla Power Conduit. Its so bloated you'll need a new Power supply!
The Linux 2.6 model sucks. 2.6, 2.8. 2.10, etc became 2.6.1, 2.6.2, 2.6.3... on short support cycles.
You, sir, do not seem to know the nightmare that maintaining separate kernels, and porting features and bugfixes back and forth, created.
2.4/2.5 model sucks, because we have to wait years before features propagate to the stable mainline kernel. Or have to resort to backporting and vendor branches.
Mozilla Alloyed Tritanium Bar oughta be great then
If you can't see the value in jet powered ants you should turn in your nerd card. - Dunbal (464142)
The waterfall model is horrible for big projects. I thought everybody knew that and had switched to the spiral model a loong time ago.
And now they add the only thing to it, that in even more horrible? Agile?? Or in other words: Spaghetti coding with the motto: “If perfect planning is impossible, maybe not planning at all will work.”
No, dammit! It’s just as bad.
Maybe that’s why they try to mix them both... To get to the actually healthy middle ground.
But still, it’s silly. We have a perfectly good spiral model. Hell, the whole game industry uses it. (As far as I know.) And it works great, even on those huge 5-year projects. (Notable exception that proves the rule: Duke Nukem Forever.)
Sorry, but that will result in a huge epic failure, and probably Firefox’s death. :/
Mark my words.
Any sufficiently advanced intelligence is indistinguishable from stupidity.
(What's so bad about changing the major version shortly if something had again to be changed incompatibly? and why not keep the major version if there is only things added?)
I would say this: It's because users don't care about incompatible changes (at least to their web browser), and version numbers are as much for the user -- if not more -- than for the devs.
What is going to become incompatible if Firefox upgrades? Basically, plugins. And most of those in popular use will be updated in short order (often before release), and Firefox makes updating those painless.
By contrast, what users expect (reasonably expect, I'll add) is that if a significant feature update is done, or a significant UI update is made, or a large number of bugs are fixed, then the major version number will be updated.
Mozilla have fallen into the classic trap of trying to expand its user base via increasing features, as opposed to keeping its user base by increasing quality.
We don't need new features directly in Firefox. Plugins do that. Remember that long ago the project made a conscious choice to take a performance hit to provide third-party access into the browser via the elaborate XUL and plugins frameworks, to minimize pushing code and features onto users who don't need them.
There are 1.1... kinds of people.
Why does the Linux community have so much trouble with it, while nobody else does?
FreeBSD, for instance, manages to have several major-number releases in use at any given time. FreeBSD 9.x is in development. FreeBSD 8.x is the recommended production release. But even FreeBSD 7.x is still supported. Not only that, FreeBSD manages to get out several point releases each year, in addition to a major release. But it has none of the problems you mention.
Maybe it's a maturity thing. The FreeBSD development community is made of very talented and very experienced developers who know that you shouldn't just throw patches and features around willy-nilly. The FreeBSD user community is also more mature, willing to wait a short while for a feature to become available through the natural release cycle.
You're both right. New features getting adding to the stable kernels have done much to reduce stability between kernel versions. So much so that distros have had to pick up the slack by introducing an increasing number of patches. Have you ever looked at the patchset list for Ubuntu? There have been like 17 different kernel patchlevels for Karmic Koala since it was released in October. That's more than one patchset a week, and each patchset can have anywhere from 1-10 patches.
My blog
Mozilla have fallen into the classic trap of trying to expand its user base via increasing features, as opposed to keeping its user base by increasing quality.
It works for Microsoft.
We don't need new features directly in Firefox. Plugins do that. Remember that long ago the project made a conscious choice to take a performance hit to provide third-party access into the browser via the elaborate XUL and plugins frameworks, to minimize pushing code and features onto users who don't need them.
It was a minority browser then. Most people do not install plugins, or install very few. Most people do not want to work out which plugins are incompatible with each other. Most people judge a browser by how good it is out of the box.
-- What's Wrong with E=mc^2, The Hammock Physicist.
Our blogger then proceeds to draw a right triangle with sides E*v, E*c, and m*c^3. For velocities (v) of 0, E*c=m*c^3, or E=mc^2. Yay vectors.
The World Wide Web is dying. Soon, we shall have only the Internet.
So they need to have all the extra bloat as plugins... and then distribute a 'Firefox' with all that stuff in it, and 'mozilla lite' without the bloat.
Actually, if you compile it yourself, cant you turn off most of the bloat?
Self proclaimed typo king, and inventor of the bear destroying coffee table (patent not pending).
I concur. The "Major.Minor.Bugfix" version scheme is much more informative than Linux's arbitrary "2.6.iteration" format. The 2.6 part doesn't even matter anymore.
Major number changes with breaks in back compatibility, changes in the direction of development, major new features/architecture, etc.
Minor number changes within Major number with new features but does not affect compatibility with same Major version. Do not take away features (e.g. no regressions)
Bugfix number changes within Minor number when no new features are added, code has simply changed or bugs fixed.
The elegant solution to too much choice among plugins isn't to revamp the software development workflow, nor is it to load every conceivable feature into the default interface. (Assuming that the opposite were true, Firefox would ship with all 10,000 plugins loaded, which it does not.)
Since Firefox is starting to resemble an operating system anyway, it might be time for Firefox distributions, which default to a core consisting of functions expected of every browser, along with the small number of exceptional features/plugins/whatever which differentiate Firefox from everything else in a good way. (That would also give users tangible reasons to choose and stick with Firefox.) Otherwise, more features for the sake of more features leads to office productivity suites in which most users must download, install and load but will never use 95% of the available features.
There are 1.1... kinds of people.
It works for Microsoft.
That would be a valid argument if Microsoft and the Mozilla Foundation had similar goals; they do not. Microsoft is a multibillion-bollar global company intent on making money; Mozilla just wants to make a browser and a few related applications.
It was a minority browser then. Most people do not install plugins, or install very few. Most people do not want to work out which plugins are incompatible with each other. Most people judge a browser by how good it is out of the box.
There's a word for that. It's called 'integration'. You add new features as extensions and then you provide browser packages which include a few extensions installed by default. That way, those who do not want a particular feature can remove it.
My blog
It's not the waiting what sucks. What sucks is that the old development model was more unstable. For big projects linux with a lot of activity, long development cycles just don't work. You don't have releases, so users don't test it. Once you get out the first stable release, users notice that it's very buggy (but you still don't know all the bugs, because most users and distros are still not using it because it has too many bugs), and it takes a full year to get the codebase into a decent shape. That's what happened with Linux 2.6. They had been dropping thousands of LoC for a couple of years. Because it's a "unstable cycle", quality was not so important, the main tree was used as a repository for "work in progress" code, and even if it was important (which it isn't, even it there's a corporate policy that says that it must be) you can't measure the quality of the code, because the users are not using it.
The new model, in the other hand, allows new feaures in every release, but it's much easier to track regressions compared to the previous model. The new features are required to have some quality, they can't have serious bugs, maintainers must agree that they can be merged, and they only can be merged in the first two weeks of the 3 months development period. It allows to make progress faster, and at the same time bugginess is controlled more easily. Previously, you had a huge diff of several MB, users reporting that the huge diff was causing several bugs and regressions in their systems, and developers had to start debugging the alpha code they had written, and had not tested, two years ago. IMO, long term, it's much better for everybody. It's not surprising that FreeBSD and Solaris are using this model too, it makes sense for Mozilla to use it aswell.
Actually, if you compile it yourself, cant you turn off most of the bloat?
You or I could probably piece together an understanding of how to do that inside a working week or so via this list of fragmented documentation:
https://developer.mozilla.org/Special:Tags?tag=Build+documentation&language=en
but I don't think the rest of their intended audience of hundreds of millions of users should need to do that in order to use an efficient browser. (In the face of mobile phones and other light devices which provide fully capable browsers, pointing out that Firefox uses 200 MB less memory than any other browser is an indictment of both.)
I'd like to use a lited Gecko in a minimal skin, but not enough for me to want to spend the next 5+ years lobbying for it in their Bugzilla. (For reference, it took 10 years for the threaded document windows feature to get looked at, even though it was the standard everywhere else. Bug #40848.)
There are 1.1... kinds of people.
Or how about switching to the system the commercial world uses?
Use internal version numbers as suggested by you (or something similar, doesn't really matter) and let the marketing folk handle public version numbers.
Sad but true, typical end-users look at Firefox 3 and compare it to MSIE 8; MSIE is 5 more than FireFox, so therefore it MUST be better.
I think Windows' internal version is still at 5 or 6 or so, whereas the public number is now 7 (after the somewhat non-numeric Vista and XP and about 2001 less than 2008).
Internal version numbers are of no concern to typical end-users; they simply don't care about minor numbers. Just tale Ubuntu's system for all I care; atleast it's easy to the end-user.
Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
The waterfall model is horrible for big projects. I thought everybody knew that and had switched to the spiral model a loong time ago.
The spiral model is utterly terrible. Since the DoD moved over to it, every one of their projects is over budget, underperforming, and late.
Agile isn't all that much better. The whole point of Agile is that you can have all of these changes... but you can get that with shorter release cycles, and its pretty easy to game Agile as much as any other model.
I think waterfall is probably still the best.
This is my sig.
Patch levels don't start at 1 the day of release, they start the day they start working on the next branch. The kernel included in the installation CD was at patchset 14, the latest released one is 17 (However there were 2-3 updates that didn't change the patch level). And Lucid is already at -11 (see http://changelogs.ubuntu.com/changelogs/pool/main/l/linux-meta/linux-meta_2.6.32.11.11/changelog and http://packages.ubuntu.com/lucid/linux-image).
Mozilla Corporation's goals are substantially to do activities which bring in revenue, as with Microsoft. Mozilla's main vehicle for doing so is to package and distribute a browser through which income is generated via Google searches. To maximize revenues, they need to maximize both market share and usage of their browser.
The new focus, maximizing market share (quantity), could help, but not as much as a new strategy which maximizes both market share and usage (quality). Under those 30 MB or so of binaries, libraries and other stuff, I'm sure exists a small feature subset set which would give all Internet users a compelling reason to switch to and stick with Firefox, if that feature subset were promoted correctly.
Based on their list of "new features", http://www.mozilla.com/en-US/firefox/features/, they don't seen to know what makes Firefox special.
Private Browsing - "Surf the Web without leaving a single trace." Which inaccurately describes the functionality. Safari and Chrome can forget things in the browser, but the Firefox feature as stated requires third-party anonymising proxies or such. ... Using substantially the same database as IE and Chrome. ... No thanks. We got here without bringing MySpace all the way to the desktop. Also does not enhance the functionality of the browser.
Password Manager - "Remember site passwords without ever seeing a pop-up." - Most browsers have had features to remember form fields since the 1990s?
Awesome Bar - "Find the sites you love in seconds (and without having to remember clunky URLs)." This is better than bookmarks/favourites?
Super Speed - "View Web pages way faster, using less of your computer’s memory." OK.
Anti-Phishing & Anti-Malware - "Enjoy the most advanced protection against online bad guys."
Session Restore - "Unexpected shutdown? Go back to exactly where you left off." Tires unexpectedly fall off? Can I have a browser that doesn't need to have this feature?
One-Click Bookmarking - "Bookmark, search and organize Web sites quickly and easily." It doesn't trouble me to click once or twice to bookmark something in any other browser, but OK...
Easy Customization - "Thousands of add-ons give you the freedom to make your browser your own." OK. But there's a handy guide to navigate those thousands, right?
Tabs - "Do more at once with tabs you can organize with the drag of a mouse." Like every other browser?
Personas - "Instantly change the look of your Firefox with thousands of easy-to-install themes." Instantly change the look of your windshield with thousands of
There are 1.1... kinds of people.
It's not about the version numbers but the development model. Basically, "do we add some features in the stable branch and make frequent releases, or do all new features go only into a dev branch that gets stabilized and released only rarely?"
"When I first heard Daydream Nation it quite frankly scared the living shit out of me." -- Matthew Stearns
All deployments end with "Doh!" and are fixed and redeployed.
About:plugins
Peripheral attachments to a central code structure, which slow down the core code, consume resources, and cause potential errors. Note that it is possible to create and publish potentially malevalent plugins, witness Microsoft's recent dotnet plugin fiasco.
'Nuff said?
"Windows is like the faint smell of piss in a subway: it's there, and there's nothing you can do about it." - Charlie Br
You know that it is silly, that every time a new version of FF comes out, every add-on author has to up the version on his code and resubmit to amo? Most of the changes from version to version of FF does not affect most addons at all and yet there is this whole thing with addons having to be resubmitted, wait in the queue for weeks and at the end the only change in the new version is the maxVersion tag in the installation rdf.
On the other hand there is now talk of completely changing the system of interfaces between addons and the browser. Who has time and interest to rewrite the same thing over and over again?
You can't handle the truth.
If the plugin architecture has become a problem (and it has due analogs of shared memory and lack of process isolation leading to potential security issues), then they should work to revise or remove it. Moving to an gushing agile waterfall feature stream or whatever development and release paradigm isn't a plausible solution.
Firefox reminds me of Windows 3.1 in an uncomfortable number of ways. Besides their co-operative multi-tasking environments and storing system settings in several different places, they share in common a very low barrier to entry with respect to writing userland apps (copy and paste some XML and JS to make a Firefox plugin, draw some boxes and remember BASIC to make a VB3 app) which enabled almost unlimited customization to occur very easily. This is good for adoption and getting onto many desktops, but leads to an ecosystem rich in poorly conceived and implemented applications which are vulnerable to each others' weaknesses.
I've seen discussions about how the plugin architecture and XUL may be revised to get rid of some of these concerns (and to get rid of some of the 5-12 layers of indirection and abstraction for some routine function calls), but I'm not confident that they will completely avoid the downfalls of analogous architectural changes made in Windows 95.
There are 1.1... kinds of people.
Mozilla Corporation's goals are substantially to do activities which bring in revenue, as with Microsoft. Mozilla's main vehicle for doing so is to package and distribute a browser through which income is generated via Google searches. To maximize revenues, they need to maximize both market share and usage of their browser.
Mozilla Corporation is a wholly-owned susidiary of the Mozilla Foundation. As such, it's revenue-raising activities are limited in scope to assist in raising money for the Foundation and to fund development activities for Mozilla's projects.
As such, Mozilla Corporation is profit seeking only in as much as it furthers Mozilla Foundation's goals.
Under those 30 MB or so of binaries, libraries and other stuff, I'm sure exists a small feature subset set which would give all Internet users a compelling reason to switch to and stick with Firefox, if that feature subset were promoted correctly.
See Epiphany and Chrome/Chromium. These projects are exactly that, but they're based on the leaner and faster Webkit libraries, rather than Gecko. Firefox aims to be a full-featured product, as you mention; the others aim at being lightweight and promoting Web standards, which were Firefox's original goals.
My blog
I'm sorry, but *every* UI-centric application development model should follow any flavour of User Centred Design.
var sig = function() { sig(); }
Wait... wasn't Firefox the "de-bloated" Mozilla?
Program Intellivision!
"The waterfall model is horrible for big projects."
Given that the waterfall model was merely a straw-man, it's best not to use it for anything.
I seem to recall those being Mozilla Suite (now Seamonkey)'s goal. FireFox's goal was to be a lighter-weight version of the Mozilla Browser.
GLaDOS for President 2016! "Well here we are again. It's always such a pleasure." -- GLaDOS, 2011
I think you'll find that it is the otherway around: release dates will get a lot harder to hit because less time appears to pass for the fast moving developers compared to the rest of the planet. Also mass (not weight!) is an invariant quantity so there will be no change. Yes I know that a lot of people often think that the mass increases but it does not the 'gamma' factor in momentum comes from the velocity NOT from the mass which is why things like "F=gamma ma" do not work.
Windows' internal version is still at 6 mostly for application compatibility reasons, nothing else.
I'm Rocco. I'm the +5 Funny man.
So apparently "6" is the correct major version as defined by "only changes when backwards compatibility breaks".
Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
Obviously, DNF, if completed, would have had some sort of feature that generated Higgs bosons.
the preceding comment is my own and in no way reflects the opinion of the Joint Chiefs of Staff
How do you know that Mozilla are not improving quality? If you pay attention, Mozilla are improving the quality of the codebase (memory consumption/leak fixes, crash fixes, etc.).
And while plugins do add some features, what about HTML5 support? Support for SMIL animations in SVG? Out of process plug-ins? Better JavaScript performance? Support for additional emerging and evolving standards? Better OS integration on Windows, Mac and Linux? Hardware-accelerated page rendering? WebGL support? And much more.
I much prefer the "someone just please code the damn thing" model.
I think a typical yet reasonable school of thought is that the best model depends on the characteristics of the project. Some projects are very fluid and some projects are very constrained. Designing the next cool iPhone game versus programming a perfect clone of last month's cool iPhone game.
So apparently "6" [in the Linux kernel] is the correct major version as defined by "only changes when backwards compatibility breaks".
Touché, good sir.
It was worse than that. The lag prompted several maintainers and distros to backport changes and the result was *two* unstable branches. I recall trying to get a new server online only to discover that the old kernel would crash on boot and the new kernel would crash randomly afterwords.
With the new development model it has been much easier for me to keep stable systems.
Less an expert, more a pattern-finder response:
In the world of Free (Gratis + Libre) open source software (FLOSS?) there's little need to waste time patching an older system when everyone has free access to a newer system that's backward compatible.
That job is left to distribution owners (like Ubuntu whose October 2008 "LTS" is still patched by them).
This process optimization that allows faster developer progress (including testing) to mean more frequent improvements.
Science & open-source build trust from peer review. Learn systems you can trust.
You're right, they don't. I'm being over-general here, of course. But patch levels do start at one during development of the distro, and that they went through 14 patchlevels before release day is still very telling.
My blog
Like H.264?
Dilbert RSS feed
"In the world of Free (Gratis + Libre) open source software (FLOSS?) there's little need to waste time patching an older system when everyone has free access to a newer system that's backward compatible."
It's only that in too many times it tends to be *not* so backward compatible.
I believe we should use Heisenberg's development model.
Due to the Heisenberg Uncertainty Principle the outcome of this development process is uncertain.
Could be a webbrowser or ... maybe an os.
But then ... we will never be able to determine what was actually developed, will we?
"Bingo. It is a pickle, no doubt about it. Bad news is there's no way you can really know if it's an os or a webbrowser. So it's really up to you. Just have to make up your own damn mind."
Maybe the Lorentz development model is better actually: It (Lorentz transformation) reflects the surprising fact that observers moving at different velocities report different orderings of events.
Mozilla reports "Bug fixed". User reports "Bug not yet fixed".
yuk - even with the Lorentz development model, the Heisenberg Uncertainty Principle still applies. We still can't tell for certain if a bug was fixed or not.
I give up.
If you don't get the new supply, you'll end up with a Mozilla Melted Capacitor Console.
Not a sentence!
But what if new features are introducing new memory leaks and crashes, etc.?
Clever signature text goes here.
Uh, the primary goal of the Lorentz branch is to merge the out-of-process plugins architecture back to the stable 1.9.2 branch that Firefox 3.6 was released from.
It's certainly possible, but we do have an extensive set of unit tests and performance tests these days, and we don't land new features without a test suite. Combined with our crash reporting infrastructure, I have pretty high confidence that the quality of the software is improving.
Yes, Firefox 3 will include a Virtual UPS.
Igor Presnyakov stole my hat
Mozilla have fallen into the classic trap...
the best known of course is "never get involved in a LAN war in Asia".
Yes, the kernel is less stable between releases. I'm failing to see why this is an issue.
If you want a stable kernel, you can use a late release candidate, a release kernel, or one of the stable kernels. As an end user you can just punt and use a distribution's kernel, which will probably be on par with a stable kernel, but much larger since they have to support pretty much everything with a limited number of builds.
Distributions aren't picking up anyone's slack. What distributions do is pick a kernel version that has what they think is a good tradeoff between features and stability (with some other considerations I'm glossing over), and then proceed to tweak it for extra stability with their particular set of applications, often by cherry-picking stability fixes from continuing kernel development and backporting them to their target kernel. Note I'm NOT saying that is all they do, they often develop their own fixes, which sometimes get pushed upstream to mainstream kernel development. Then they continue to apply fixes to the kernel as they appear for longer than the kernel hackers are generally interested in doing.
Each distribution strikes a balance between features, stability, schedule, and other issues, and there are entirely too many distributions for the kernel hacker community to keep track of, much less address all their issues.
A final note, the dichotomy between distribution engineers and kernel hackers isn't all that clear a line, very often it's actually the same people doing the work on both sides of this imaginary fence.
How do you know that Mozilla are not improving quality?
Read carefully:
"as opposed to keeping its user base by increasing quality"
If quality was the primary focus, more than one of the "Top Features" of Firefox 3.6 would pertain to quality. "Super Speed" points out some rendering benchmarks as compared to previous versions of the browser. Since Firefox has been instrumented as you describe, it should be possible to state that Firefox 3.5 outperforms Firefox 3 in quality terms (x% decrese in memory consumption for a common use case, specific number of memory leaks fixed, frequency decrease in crashes).
It may be that Firefox is enhancing quality, but the preponderance of communication to recruit/retain users focuses on features, and not on quality.
There are 1.1... kinds of people.
Under those 30 MB or so of binaries, libraries and other stuff, I'm sure exists a small feature subset set which would give all Internet users a compelling reason to switch to and stick with Firefox, if that feature subset were promoted correctly.
Except for whatever browser comes with windows, which many users don't know about, and for sites which force users to use IE, such as activex, etc, which are several. I work in a cyber cafe with about 100 inexperienced users a day. Many of them actually are arrogant with me saying IE is better, it always works with the site. And unfortunately, with many sites, I will be forced to admit it is true - without IE and windows, you can't get your job done, things won't work. It happens on government sites and bank sites, occasionally.
Build your own energy sources from scratch. http://otherpower.com/