×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Implications of the Mozilla/Adobe Partnership

Zonk posted more than 7 years ago | from the joint-company-picnics dept.

104

Fraggle writes "Recently the Mozilla Foundation and Adobe announced a partnership, working together on the next generation JavaScript/ActionScript JIT Virtual Machine. The Browser Den looks at what this means for the future of scripting in Mozilla, and how this partnership with Adobe may affect Mozilla's support for other technologies such as SVG." From the article: "On the Mozilla side the plan is to integrate to code with SpiderMonkey which is Mozilla's current JavaScript implementation that is written in C. This is needed because Tamarin is not a drop-in replacement for SpiderMonkey as it provides necessary features that are not available in Tamarin. The combined SpiderMonkey with integrated Tamarin should not have any problems with old JavaScript and should show a performance boost for most. However, skilled scripters are sure to find ways of optimising performance to get even more gains."

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

104 comments

Is Open Source finally ready for prime time? (1)

October_30th (531777) | more than 7 years ago | (#16793896)

First the Novell/Microsoft deal and now this?

Re:Is Open Source finally ready for prime time? (1)

LiquidCoooled (634315) | more than 7 years ago | (#16793942)

I was thinking the opposite.
If big business is trying to muscle in, then we should all run for the hills.
Is itsatrap relevant here?

I might be overreacting, and we already have one big benevolent overlord guiding us (the Vorlons ermmmmm I mean IBM), do we need others?

Re:Is Open Source finally ready for prime time? (2, Insightful)

October_30th (531777) | more than 7 years ago | (#16794040)

To quote the real Kosh: "The avalanche has already started; it is too late for the pebbles to vote." ;)

Re:Is Open Source finally ready for prime time? (1)

baadger (764884) | more than 7 years ago | (#16796238)

It isn't a trap because it's impossible to trap anyone all the time the code is GPL'd. IceWeasel could easily benefit from this code as well (although i'm not saying I support IceWeasel or oppose the Adobe/Mozilla partnership).

The *worst* that could happen is the Mozilla/Firefox 'brand name' becomes tainted and people move away from it in droves. How this could feasibly happen I don't know, it isn't likely at all. Either way I couldn't give a monkeys butt about the brand, I care about the product. So I really wouldn't care if it was *Microsoft* or Satan himself GPL'ing some JavaScript engine, if it improves Firefox's JavaScript performance then w00t!

The MS/Novell deal is a whole different Kettle of Fish.

Re:Is Open Source finally ready for prime time? (1)

Bing Tsher E (943915) | more than 7 years ago | (#16800894)

Either way I couldn't give a monkeys butt about the brand, I care about the product.

True to a degree. But the 'brand' of OSS projects is the center around which developers gather. If the 'brand' is subverted or branches out in a way that dissipates that center, then developers will disperse and/or cease to participate.

'The Mozilla Project' is a distinctily different 'brand' than 'Adobe (tm) Mozilla.'

Personally, I try to stay at arms length from anything currently made by Adobe. They've been taken over by types who add in thick layers of garbage. Recent incartions of Acrobat Reader, and the whole Adobe approach to PDF, reflect this. And I am a paid licensee of several older versions of Acrobat.

Re:Is Open Source finally ready for prime time? (1)

ubuwalker31 (1009137) | more than 7 years ago | (#16794772)

Oh boy, I can't wait for the Adobe Acrobat Plug-in toolbars and such....*sigh*

Re:Is Open Source finally ready for prime time? (1)

Bing Tsher E (943915) | more than 7 years ago | (#16800922)

I now use Foxit Reader almost exclusively for displaying and printing PDFs at work. But my machine still sometimes locks up and throws up dialogues about AdobeAcrobat plugin junk. I haven't taken the initiative to completely excise Adobe Acrobat from the machine (the IT people might frown on that) but Foxit Reader is a single .exe file that I can stick essentially anywhere on my drive and point PDF files at, and it just works(tm).

Amazing (2, Insightful)

BadAnalogyGuy (945258) | more than 7 years ago | (#16793930)

Never in my wildest pre-crash dreams did I ever think that Javascript would become a respectable programming language.

HTML either, but that preconception was crushed when I saw the money those art school dropouts were making.

I just hope that they don't embed Flash player into the browser. That would suck royally.

Re:Amazing (2, Interesting)

foniksonik (573572) | more than 7 years ago | (#16794200)

"I just hope that they don't embed Flash player into the browser. That would suck royally."

Don't disparage something you don't understand. It's like saying you hate all music cause you heard a few Britney Spears songs.

Take a look at OpenLaszlo. [openlaszlo.org]

Re:Amazing (1)

ultranova (717540) | more than 7 years ago | (#16795132)

Don't disparage something you don't understand. It's like saying you hate all music cause you heard a few Britney Spears songs.

No, it is like saying you don't want a radio without an "off" button.

Most Net Flash content is crap. It's mainly used for ads. I, for one, surf with FlashBlock and only allow the damn thing to play when absolutely neccessary.

Re:Amazing (1)

a.d.trick (894813) | more than 7 years ago | (#16795712)

Don't disparage something you don't understand.

I can't speek for the GP, but I understand Flash. Flash is about giving control to the content producers at the expense of the consumers. I am a comsumer who likes control, ergo I don't like like flash.

Re:Amazing (1)

RicktheBrick (588466) | more than 7 years ago | (#16795920)

I am using a 64 bit Ubuntu 6.10 operating system with the latest firefox 2.0 browser. I can not get any flash to work or any video player. I tried downloading from Adobe and they state they do not support 64 bit. I tried automatix and downloaded a 32 bit firefox and when I download the plugins I get a error message. If I retry to install them, the programs states that they are already installed but when I tell it to reinstall them I get the same error I got before. I like this 64 bit firefox because I will load in about 5 seconds where all of my 32 bit systems take between 30 and 45 seconds to initially load but I just can not watch any youtube, cnn videos or any site that uses flash.

Re:Amazing (1)

Malc (1751) | more than 7 years ago | (#16794816)

I've seen some very slick applications written in JavaScript. It can be quite powerful. One feature I really like and put to good use is the eval method - take any string and treat it as a piece of code and run it. It also does some funky things with enviroment contexts (can't remember the right term) where you can define a function that references a variable in the outer function, then pass function off to somewhere else. Later on when you call it from some unrelated code, the variable in the outer function is still valid. I haven't been able to do that since I stopped programming in SmallTalk many moons ago.
function getFn(i)
{
    var fn = new function fnInner()
    {
        alert("Variable = " + i);
    }
 
    return fn;
}
//...
var fn = getFn(4);
//...
fn();

Re:Amazing (1)

cyber-vandal (148830) | more than 7 years ago | (#16795536)

One feature I really like and put to good use is the eval method - take any string and treat it as a piece of code and run it

I know Rexx and VBScript can also do that and I'm sure they're not the only ones. It's very handy but hardly unique.

Re:Amazing (1)

Malc (1751) | more than 7 years ago | (#16796218)

No, but the point is is that JS is powerful and useful. The OP was surprised by this.

Re:Amazing (1)

FLEB (312391) | more than 7 years ago | (#16800148)

Any interpreted scripting language worth its salt usually provides a code-string running mechanism. It's one of the primary benefits of being an interpreted, as opposed to compiled, language. If you're already interpreting uncompiled code, what's more uncompiled code in the mix?

Re:Amazing (0)

Anonymous Coward | more than 7 years ago | (#16795718)

Typically called closures.

Not all that rare in modern languages - perl also supports closures, for instance.

Re:Amazing (1)

MORB (793798) | more than 7 years ago | (#16795086)

I'm toying around with embeddable language interpreters to use in my current hobby project, and I'm very fond of lua.

I recently discovered javascript, which I didn't give much attention before, and I was surprised to discover that it's actually a pretty good language. It pretty much does all the things I like in Lua (functional programming among other things), and even a few more things that could be useful to me.

The downside is that lua currently beats the crap out of it when it comes to performance.
The new JIT VM from adobe should reverse this tendency (at least regarding speed, maybe not regarding memory footprint).

It might become a very interesting choice.

Re:Amazing (0)

Anonymous Coward | more than 7 years ago | (#16795160)

I meant to link this [debian.org] to elaborate on the performance thing, but I fumbled the html.

Re:Amazing (1)

mad.frog (525085) | more than 7 years ago | (#16796452)

The downside is that lua currently beats the crap out of it when it comes to performance. The new JIT VM from adobe should reverse this tendency (at least regarding speed, maybe not regarding memory footprint).

Some speed benchmarks of Tamarin vs. Spidermonkey are here [playercore.com].

Some additional benchmarks of Flash Player 9 (which is essentially identical to Tamarin in this context) vs SpiderMonkey can be found here [oddhammer.com].

Re:Amazing (0)

Anonymous Coward | more than 7 years ago | (#16797732)

Lua is already faster [debian.org] than most dynamic typed runtimes, add a JIT to lua [luaforge.net] and it's register based VM becomes competitive with Java [debian.org] and Mono. [debian.org]

I've seen a tamarin "typed" benchmark and heard people say it is slow on eval, ie: code as data in a dynamic language. From this I assume tamarin is stack based and that the VM is not suited to dynamic languages (like javascript). If I'm right, Mozilla have only chosen tamarin because Macrodobe are willing to donate engineering resources. I'd like to see a benchmark and comparison between neko JIT and tamarin, something similar to this comparison between neko and lua. [nekovm.org]

Re:Amazing (1)

FooAtWFU (699187) | more than 7 years ago | (#16797958)

Never in my wildest pre-crash dreams did I ever think that Javascript would become a respectable programming language.
From Javascript: The World's Most Misunderstood Programming Language [crockford.com]:
Despite its popularity, few know that JavaScript is a very nice dynamic object-oriented general-purpose programming language. How can this be a secret? Why is this language so misunderstood? ...

...JavaScript's C-like syntax, including curly braces and the clunky for statement, makes it appear to be an ordinary procedural language. This is misleading because JavaScript has more in common with functional languages like Lisp or Scheme than with C or Java. It has arrays instead of lists and objects instead of property lists. Functions are first class. It has closures. You get lambdas without having to balance all those parens.

(Later portions of the document comment on some of the issues, including but not limited to "Substandard Standard" and "Lousy Implementations" and "Bad Books" and "Amateurs".)

There goes the neighborhood (1, Funny)

72beetle (177347) | more than 7 years ago | (#16793948)

Oh well, what's the next killer open source app that we use to thumb our noses at the man? This one's been assimilated.

Say What? (5, Insightful)

AKAImBatman (238306) | more than 7 years ago | (#16793954)

On the Mozilla side the plan is to integrate to code with SpiderMonkey which is Mozilla's current JavaScript implementation that is written in C.

I presume the article means to say that the Tamarin engine will be coupled with SpiderMonkey's APIs? Because I don't see how you could "combine" two separate Javascript engines and expect a usable result. That would be like "combining" Windows and Mac OS X to make a better operating system. It doesn't quite work that way.

Re:Say What? (4, Informative)

BHearsum (325814) | more than 7 years ago | (#16793990)

Tamarin has a JIT compiler for faster execution of a lot of Javascript code. I imagine that is a big part of what is going to be intergrated.

Re:Say What? (1)

niteice (793961) | more than 7 years ago | (#16794858)

Tamarin has a JIT compiler for faster execution of a lot of Javascript code.
That's one of the reasons there's no 64-bit Flash. Who wants to bet on Mozilla having an amd64 JIT first?

Re:Say What? (0)

Anonymous Coward | more than 7 years ago | (#16795044)

I bet on neko [nekovm.org] having AMD64 JIT first.

Re:Say What? (1)

mjbkinx (800231) | more than 7 years ago | (#16796274)

I bet on neko having AMD64 JIT first.

I wouldn't be so sure, there will be many more working on Tamarin then on the Neko VM [nekovm.org].
But who cares which one will be first, haXe [haxe.org] can be compiled for both. :)

Re:Say What? (4, Funny)

dsginter (104154) | more than 7 years ago | (#16793992)

That would be like "combining" Windows and Mac OS X to make a better operating system. It doesn't quite work that way.

That sound you hear is the thousands of Microsoft Windows programmers kicking the dirt and going back to the drawing board.

Re:Say What? (1, Informative)

Anonymous Coward | more than 7 years ago | (#16794060)

They basically mean combine SpiderMonkey's JavaScript compiler with Tamarin's JIT. So SpiderMonkey ends up compiling the JavaScript code down to some kind of intermediate format (which it already does), feeds that to Tamarin, which generates native code from that.

It's kind of like the LLVM project's C++ compilers - they took GCC, and modified it to produce LLVM bytecode which could be fed into their own JIT.

Re:Say What? (1)

clickclickdrone (964164) | more than 7 years ago | (#16794312)

>That would be like "combining" Windows and Mac OS X to make a better
>operating system. It doesn't quite work that way.
FX: Head of Vista development team "Doh!"

Re:Say What? (1)

Wesley Felter (138342) | more than 7 years ago | (#16796644)

That would be like "combining" Windows and Mac OS X to make a better operating system. It doesn't quite work that way.

Why not? OS X is a train wreck of OS 9, BSD, Mach, and NeXT code and it works pretty well.

Will this ever see the light of day? (1)

the-stringbean (884738) | more than 7 years ago | (#16794110)

What I want to know is when will we actually see any benefits from this?

From TFA:

Tamarin is expected to make its Mozilla debut with Mozilla 2. Mozilla 2 is not actually a product release but is the version of the underlying framework. Mozilla 2 is not expected to be ready by 2008 at the earliest. Firefox 3 will be based on the Mozilla 1.9 framework, it is not sure at this time which Firefox release will use the Mozilla 2 framework.

So we have FX 3 being based on Mozilla 1.9 which means it will most likely be at least FX 3.5/4 (depending on the naming convention). Which means there isn't going to be a release that uses this until sometime between the tail end of 2008 and 2010.

I know there is going to be some serious amount of work involved but 2-4 years? That's a lot of technology advances...

Re:Will this ever see the light of day? (1)

richwklein (767820) | more than 7 years ago | (#16795660)

It has to be that long before it can be implemented. The implementation depends on the ECMAScript 4 specification. ActionScript 3 is based off of that spec while Javascript 1.7 is based on the ECMAScript 3 spec. The reason ECMAScript 4 is so important is that it allows for strong typing of variables. That strong typing allows Tamarin to compile the script down to machine level code. If strong typing is not used then the script must be interpreted at runtime.

Re:Will this ever see the light of day? (1)

kbrosnan (880121) | more than 7 years ago | (#16798030)

Gecko 1.9 will be shipped in Firefox 3, currently scheduled for the May or November 2007, depending on which part of the Mozilla Wiki to belive*. From what I understand there are plans to release a Firefox 4 off Gecko 1.9, much like Firefox 1.5 and Firefox 2 are built off Gecko 1.8. So that would put these changes in Firefox 5 time frame, yes this is quite some time away.

* http://wiki.mozilla.org/Firefox3/Schedule [mozilla.org]
* http://wiki.mozilla.org/ReleaseRoadmap [mozilla.org]

However, skilled scripters are sure to.. (2, Funny)

Trigun (685027) | more than 7 years ago | (#16794164)

However, skilled scripters are sure to find ways of optimising performance to get even more gains."

Like having Samy as your hero.

Good news (3, Informative)

WickedLogic (314155) | more than 7 years ago | (#16794188)

At the ajax experience [theajaxexperience.com] Brendan Eich spoke about this and without mentioning company names. The boost in performance in JS will cement web application's future and will bring javascript to the forefront even more as the power language that it is. Combine that with JSON [json.org] and the module tag [json.org] proposal, it should be some very interesting times.

That's swell (1, Interesting)

Anonymous Coward | more than 7 years ago | (#16795246)

Now all we need is a solution to the security problem caused by sites having the abilty to run arbitrary script to begin with. Javascript is great language and I look forward to my browser extensions running on a VM with a JIT, however AJAX is still going to be an inaccessible toy.

Re:Good news (0)

Anonymous Coward | more than 7 years ago | (#16797622)

The boost in performance in JS will cement web application's future and will bring javascript to the forefront even more as the power language that it is.


Try saving a file to disk client side from JS. Try enabling javascript in a browser with javascript disabled by the administrator from javascript.

Power what? Power useless crap. JavaScript is guaranteed to die horribly, it is an absurd idea.

Want to write a real cross platform application that can actually do something useful? Try C.

Re:Good news (1)

FLEB (312391) | more than 7 years ago | (#16800220)

Try saving a file to disk client side from JS.
True.

Try enabling javascript in a browser with javascript disabled by the administrator from javascript.
That's like asking C to press the power button on your computer for you. If it's not turned on, it's not turned on.

Lots and lots of implications (5, Informative)

suv4x4 (956391) | more than 7 years ago | (#16794190)

For those who don't follow the project tightly, there are indeed a slew of implications.

On the side of Mozilla, it means much faster, JIT JS engine, and since you know that Firefox's XUL depends heavily on JS to run, it may have big impact on the performance of Firefox as a whole and change the perception some have of Firefox as "bloated" and "slow".

This is just a guess though. Here's what's really fun.

Adobe is now working on its next generation "web platform", code named Apollo. Apollo's long term goals are to merge Flash, HTML/JS/CSS and PDF in one single "web platform", for internet applications.

Apollo is not a browser, you can think of it sort of like the .NET or Java runtime. Or well, Adobe wants you to think that.

The first version of Apollo is not going to merge all three technologies into one, but it'll integrate them to work together. This means, you can have Apollo app that is based on AJAX with flash in it. Or Flash project with HTML in it. Or, I guess, Flash with PDF in it.. All sorts of combinations.

Adobe announced that they will NOT develop a browser on their own for Apollo, and that they are researching what to use.

I'll be honest, I thought it's apparent they'll pick Opera. Opera is faster than Firefox, it's portable to mobile platforms (and this is important to Adobe), and both Macromedia and Adobe have rich partnership with Opera already.

For example, Dreamweaver's WYSIWYG on Mac used to be Opera for a long time, and maybe it still is (on Windows, as far as I know, it's custom built).

And even now, the entire help system of Adobe uses built-in Opera browser. Even their "Bridge" image browser, is in fast running on Opera.

But now, as they contribute big chunks of Flash 9 (the script engine) to Mozilla, it means only one thing: Adobe has decided on a browser.

Apollo will feature a version of Gecko with Tamarin for a script engine.

Currently Adobe Reader (PDF) uses SpiderMonkey for its script engine, but when Tamarin is good enough to replace SpikerMonkey in Firefox, it'll be good enough to do it in Adobe Reader.

Hence, one step forward towards Adobe's vision of unified HTML/Flash/PDF platform. Interesting times.

Re:Lots and lots of implications (5, Informative)

larkost (79011) | more than 7 years ago | (#16794322)

Actually, it has been anounced [blogs.com] that Apollo will be based on WebKit, the framework that is behind Apple's Safari. They will be using the open source version rather than Apple's internal version, but the differences are minor.

Re:Lots and lots of implications (2)

suv4x4 (956391) | more than 7 years ago | (#16794354)

Actually, it has been anounced that Apollo will be based on WebKit, the framework that is behind Apple's Safari. They will be using the open source version rather than Apple's internal version, but the differences are minor.

Interesting, didn't know that. It's strange that of all browsers on the market, Adobe will pick the least popular one, and one which needs a lot of work before it even runs on Windows (I know work is being done on it, but it's far from done).

Re:Lots and lots of implications (2)

mbwjr12 (939334) | more than 7 years ago | (#16795106)

Yes, but that work is minor compared to fixing Gecko's bloated code base. I'm sure Adobe chose KHTML (That is the real name WebKit) for the same reasons Apple did when building Safari: it's clean, it's fast, and it's standards compliant. I believe that KHTML (as Konqueror on KDE, and Safari on Mac) is the only engine currently passing the ACID2 compliance test. The guys on the KDE team have done an excellent job. In addition, Apple has already shown that it's not a big deal to port KHTML.

Re:Lots and lots of implications (2)

Tim C (15259) | more than 7 years ago | (#16795300)

Apple has already shown that it's not a big deal to port KHTML

Not to belittle their work, but they did "only" port it from one Unix-like system to another. Porting it to Windows will be rather more work, I suspect.

Re:Lots and lots of implications (1)

pherthyl (445706) | more than 7 years ago | (#16796404)

Well given that it has already been (partially) done, by one or two people working in their spare time, I doubt it's as difficult as you think.
See here (it seems to be now defunct, but they did have a working release out at one point):
http://en.wikipedia.org/wiki/Swift_(web_browser)/ [wikipedia.org]

Re:Lots and lots of implications (1)

bdash (598142) | more than 7 years ago | (#16802596)

Just to clear things up a little... The initial port of WebKit to Windows was done by developers that were already active in the WebKit community. This involved refactoring the WebCore library to be less tied to Mac OS X, and implementing Windows-specific portions of the code when required. A small browser-like application named Spinneret was developed for use in testing WebCore on Windows, the first version of which made its way into the WebKit source code repository in January this year.

For the majority of the time since Janurary, WebCore has continued to function on Windows. Various improvements have been contributed, both from people within Apple and members of the open source community. The most common changes in recent times have been minor fixes to ensure that the code compiles on Windows (most of the developers on WebKit work on Mac OS X and some of their changes cause the Windows port to fail to compile).

The Swift web browser makes use of WebCore in a similar way to how Safari uses it: it embeds the WebCore-rendered page in a host application which provides the browser user interface. To suggest that the port of WebKit to Windows was done "by one or two people working in their spare time" is grossly misleading, and is assigning credit for the work to those that did not perform it.

Re:Lots and lots of implications (1)

notneverwired (782950) | more than 7 years ago | (#16794774)

From the way that blog entry is written it seems webkit and Apple's WebKit are similar only in name. Aren't they different things?

Re:Lots and lots of implications (1)

bdash (598142) | more than 7 years ago | (#16802606)

No, the blog post is just worded in a somewhat misleading manner. The text used, "WebKit is an open source web browser engine. WebKit is also the name of the Mac OS X system framework version of the engine that's used by Safari, Dashboard, Mail, and many other OS X applications.", is taken from the homepage of the WebKit project over at http://webkit.org/ [webkit.org]. It is most definitely the same thing used in Safari on Mac OS X.

Is Adobe/Macromedia losing it? (2, Interesting)

pubjames (468013) | more than 7 years ago | (#16794418)

When Macromedia started, they made great tools. They looked at what professional web developers wanted, and made neat tools to fulfil their needs. Unfortunately, for a while now they have been operating in an entirely different manner - they have been deciding where they want the technology to go, and then trying to push tools that fulfil their vision onto web developers.

This has meant that their core products, such as Dreamweaver and the Flash development application, have been rapidly becoming crappier. Dreamweaver is now annoying as hell to use, and does work well with some of the technologies that developers like to use (PHP, for instance) because those are not technologies Macromedia/Adobe what to promote. And for ages they have been trying to get developers to use Flash to develop applications, which just isn't happening.

Personally, I think Macromedia/Adobe are going to suffer as developers reject their tools and start using open source ones.

Curse your sudden but inevitable betrayal (1)

Serious Callers Only (1022605) | more than 7 years ago | (#16794464)

Hence, one step forward towards Adobe's vision of unified HTML/Flash/PDF platform. Interesting times.

I find this idea a bit scary. HTML, Flash, and PDF do two completely different things, and attempting to combine them is not going to end with a super-browser but with a monstrous train-wreck something like Acrobat Viewer, which inserts buttons in my excel toolbar without asking, takes forever to load and is generally a waste of space.

This announcement alone doesn't mean that Adobe will take this direction, but it does seem to be their strategy given the lack of emphasis on SVG lately and the purchase of Macromedia. Given Adobe's recent purchase of their main competitor, their sluggish response to market changes like OS X Intel, and the general bloat in their flagship products (which I use every day. but find increasingly frustrating and buggy), this doesn't bode well for the development of the Internet. It's too easy for them to translate control over one of the main browsers into an irresistible push for the internet in the direction that they want it to go.

Apollo's long term goals are to merge Flash, HTML/JS/CSS and PDF in one single "web platform", for internet applications.

A web platform owned by Adobe. It's interesting how closely this strategy mirrors that of Microsoft, which is to pollute the Internet space with de-facto standards (.NET is named that way for a reason) which make using anything but software released by them for creation/viewing difficult. It's the same story with Apple and the iTMS, and I guess it works sometimes, but surely long-term people always see through this attempt to create a walled garden?

Re:Curse your sudden but inevitable betrayal (1)

99BottlesOfBeerInMyF (813746) | more than 7 years ago | (#16797590)

I find this idea a bit scary. HTML, Flash, and PDF do two completely different things, and attempting to combine them is not going to end with a super-browser but with a monstrous train-wreck something like Acrobat Viewer, which inserts buttons in my excel toolbar without asking, takes forever to load and is generally a waste of space.

There's not a lot of point in integrating tools that do the same thing. The functions of Flash, PDF, and HTML are complementary. Not that it means any given toolset to work with them is going to be a good one, but really the Web right now is already built on these formats along with the scripting they're throwing their weight behind. Allowing (but not requiring) the integration of these might be a real boon

Given Adobe's recent purchase of their main competitor, their sluggish response to market changes like OS X Intel, and the general bloat in their flagship products ...

I agree the last item here is an issue, but the first two are not really. I'd rather there was more competition, but none of this was anything that undermines the free market. It just changes the players. As for the "sluggish" response to OS X on Intel, it could have been faster, but given that they were in the middle of a major merger, I'd say the ports haven't been too slow. Adobe's customers are somewhat conservative, and a slight wait for full speed is not a huge deal to most of them.

It's too easy for them to translate control over one of the main browsers into an irresistible push for the internet in the direction that they want it to go.

If you hadn't noticed, a monopoly has already done that. IE has determined the direction of internet technologies, and basically made sure they went nowhere.

A web platform owned by Adobe.

I don't see Adobe successfully embracing and extending HTML/CSS. PDF is open and widely used. Javascript is likewise open and Java is moving there. That pretty much leaves Flash as their lock-in. I'm really not seeing how you expect Adobe to grab the ball and run here. This partnership with the Firefox team, current partnerships with Opera, and adoption of WebKit leaves them pretty firmly committed to Web standards at least for HTML and CSS. The opening of this scripting engine is another good sign. I remain skeptical of your theory... not that I'd put it past them to try if they thought they could, but I think they know it wouldn't fly and aren't even going to try.

It's the same story with Apple and the iTMS, and I guess it works sometimes, but surely long-term people always see through this attempt to create a walled garden?

Apple is providing a service, application, and device all neatly tied together. This is a great way to compete against an established monopoly. You build a separate, vertical chain to mitigate the monopoly abuse. It has worked well for them in the PC/OS space and they just applied it to the portable digital music player space in its infancy. For a lot of people one or more pieces of that chain make sense, and as a result the whole chain makes sense. For some a walled garden is the best choice, even knowing it is a walled garden. For others this is not the case. For me, I always ask "how high are the walls?"

Re:Lots and lots of implications (0)

Anonymous Coward | more than 7 years ago | (#16794800)

It might make it faster, but it can't help but increase the bloat. A JIT is a complicated piece of technology. Plus, I'll bet that the JIT will be x86-32bit, Windows-only, meaning that on all other platforms, all you get is a much large JS engine than includes a VM.

If Java has taught us anything, it's that a VM does not improve performance, and in fact kills it. Java programs are massive, requiring huge amounts of CPU and memory. Most scripting languages run circles around Java programs. Perl and Python get used to run some of the busiest sites in the world.

Java gets used to require some of the busiest sites in the world buy some of the most expensive hardware in the world.

A VM might make the JS engine slightly faster after the browser has completely loaded and compiled everything. But since that compilation step, and further JIT step, have to be added, ultimately, I expect it'll simply make the browser even slower and require even more memory.

Re:Lots and lots of implications (1)

mad.frog (525085) | more than 7 years ago | (#16796508)

Plus, I'll bet that the JIT will be x86-32bit, Windows-only, meaning that on all other platforms, all you get is a much large JS engine than includes a VM.

The JIT is currently x86-32 for Windows and MacOSX, plus PPC-32 for MacOSX. There is also a prototype ARM implementation. x86-32 for Linux is functional but has not yet been merged into the CVS tree. x86-64 (Windows + Mac + Linux) is under development.

OpenLaszlo is the big winner from all of this! (1)

SimHacker (180785) | more than 7 years ago | (#16796764)

The OpenLaszlo [openlaszlo.org] Legals Project [openlaszlo.org] will benefit immensely from this! OpenLaszlo is in a position to take excellent advantage of the now open source AMV2 JavaScript engine, for the benefit of users as well as developers. Not only will AVM2 make OpenLaszlo applications run faster on Firefox, but opening up the AVM2 virtual machine will make it possible to develop much more powerful debuggers and integrated development environments.

-Don

What is OpenLaszlo "Legals" [openlaszlo.org]?

"Legals" is an OpenLaszlo project to provide a single application environment that supports multiple deployment runtimes. OpenLaszlo 3.x supports Flash 7 and 8 now, but Legals will extend that reach to include DHTML as well as Flash 9. And with the necessary infrastructure in place, we anticipate further runtimes will be developed by the OpenLaszlo community.

The OpenLaszlo "Legals" project began at the start of 2006. We are projecting final availability by the end of the year. Developers interested in helping make Legals a reality are invited to contact us. Developers wishing to get a head-start building applications on top of Legals will be able to do so with our beta release in a few months.

Many people ask about the back story for the project name. The name, Legals, is a tribute to a well-known local restaurant [legalseafoods.com] in Boston where a lunch meeting inspired the team to launch this project.

See Legals FAQ [openlaszlo.org] for commonly asked questions and answers.

The Architecture

With Legals, the OpenLaszlo architecture is being remodularized into a true multi-runtime platform. OpenLaszlo generates script source that is compatible with ECMAScript Release 3, while leveraging extensions from ECMAScript Release 4. From there, multiple compiler backends generate JavaScript in the native dialect of the destination runtime: ActionScript 2 or 3, JScript 5.6, JavaScript 1.4+, and so on.

The OpenLaszlo runtime library is being refactored into two parts: multiple kernels containing runtime-specific code, and a cross-runtime library written in standard ECMA-3. As part of the runtime library, the OpenLaszlo class system has been rewritten in ECMA-3 and includes several innovative new features.

The OpenLaszlo runtime library delivers a common baseline of functionality across all supported runtimes. This gives the developer a rich environment in which to build full-featured web applications. In addition, Legals will include runtime-specific extensions so that the particular benefits of targeting a runtime are not lost to the OpenLaszlo application developer.

Re:Lots and lots of implications (0)

Anonymous Coward | more than 7 years ago | (#16798546)

Yay, browser specific web pages!

Re:Lots and lots of implications (1)

TechForensics (944258) | more than 7 years ago | (#16801614)

I wonder if it also means it will get harder to turn off annoying Flash ads when browsing with Firefox.

Credible OSS response to .NET (on the desktop) (4, Interesting)

sreekotay (955693) | more than 7 years ago | (#16794208)

Despite all the harping, .NET has been a huge success for Microsoft in Corporate/Server development. On the desktop, just as MS is afraid of Flash and Firefox (not coincidental or surprising they linked up) obviating the need for , I think Adobe, et al have been concerned about the potential impact of WPF, etc. for what they call the RIA [kotay.com] space.

Some early benchmarks [kotay.com] comparing SpiderMonkey, what would become Tamarin, and JScript.NET. are on my site [kotay.com]... interesting is that neither CLR, nor Tamarin provide a big boost when you use the features of JavaScript that make it more interesting than just plain old C. Wonder how much a real world boost this will be for the integration complexity? (i.e. is this another Netscape 6? Perhaps buckling down and fixing SpiderMonkey might serve better...)
--
graphically speaking [kotay.com]

Re:Credible OSS response to .NET (on the desktop) (2, Interesting)

laffer1 (701823) | more than 7 years ago | (#16794546)

They might be able to improve the new combined code to execute faster. This whole thing sounds a lot like Java to me. It will be slow starting up and after a page is loaded, it can execute very quickly. Based on recent research for ecommerce sites, I suspect this may have a negative impact on Firefox adoption down the road. The point of JavaScript was to make a lightweight interpreted language that could glue together other components such as plugins, later java, flash and active x controls.

I understand why some people like flash, but I don't understand why people support flash taking over. Macromedia and now Adobe support 99% of all browsers supposedly, but at the same time there are huge gaps in platform support. Its near impossible to have a new OS enter the market without support for Firefox, Flash and a slew of other things. What happens if Linux forks someday or gets so commercial the grass roots folks start over. Remember, the uniqueness of linux was that it was free. The idea of developing in an open environment started long before linux and shortly after linux was public we had 386BSD > NetBSD and FreeBSD. What if someone develops a miracle microkernel design that just works. Anything is a possibility and I think the open source community needs to take charge with Flash if we are going to push it on people. I'd rather go an SVG route where we have open source libraries for it already. A combination of SVG, and some other open source technologies could get us an equivalent to flash but it would need serious adoption to take off. Perhaps when people are tired of paying the adobe premium for Flash? To a windows developer, Adobe products are reasonable but to a Mac or OSS developer you can't beat free. As we are talking about flash as an application platform, xcode is a fair comparison here.

Re:Credible OSS response to .NET (on the desktop) (1)

Malc (1751) | more than 7 years ago | (#16794864)

Linux wasn't unique in being free. Every heard of Andrew Tanembaum (sp?)?

Re:Credible OSS response to .NET (on the desktop) (1)

mad.frog (525085) | more than 7 years ago | (#16796564)

It will be slow starting up and after a page is loaded, it can execute very quickly

Don't rush to judgement on this without looking at the code. One of the design criteria for the JIT was to avoid this problem. Flash Player 9 (which uses this VM) can load and start executing jitted code very quickly. (Is "jitted" a real word?)

Where are the applications? (0)

Anonymous Coward | more than 7 years ago | (#16797178)

Five years after the release of C#/.NET and several million dollars ($500M to novell to "buy" some "trademark") and nobody cares about .NET. Where are the applications of this platform?

Despite C/C++ and Java even perl, python, tcl and ruby have more applications than C#.

If it wasn't for Miguile de Icaza who is getting paid to make Mono and at the same time has the authority to force Mono into GNOME, nobody would know about this thing in the OSS world. RMS must clearly denounce GNOME and Mono as not being part of the GNU project.

Also note that Novell has been "Registering IL executables" at boot long before any .NET applications existed.

Re:Credible OSS response to .NET (on the desktop) (1)

killjoe (766577) | more than 7 years ago | (#16797880)

"Despite all the harping, .NET has been a huge success for Microsoft in Corporate/Server development."

No it hasn't all they have done is to convert their VB programmers to VB.NET or C# programmers and they VC++ developers to C#. It's not like they converted java programmers or anything. The truth is that VB programmers were going to "upgrade" to anything MS put out no matter what it was.

Re:Credible OSS response to .NET (on the desktop) (1)

sreekotay (955693) | more than 7 years ago | (#16798382)

On the desktop - sure, non-existent - but on the server side, I see more and more developers building, from large scale application deployments to startups, doing their apps with .NET - productivity out-weighing other factors (in their opinion, which they back up with their work :)).
---
graphically speaking [kotay.com]

itsatrap (0)

Sinbios (852437) | more than 7 years ago | (#16794566)

>> Recently the Mozilla Foundation and Adobe announced a partnership

Where's the itsatrap tag?

About SVG (2, Interesting)

supabeast! (84658) | more than 7 years ago | (#16794814)

From TFA
I've seen some theories on the Internet suggest that part of the deal with Adobe was to remove the native SVG support from Firefox effectively reducing the competition for Flash.


There's no need for Adobe to make such a deal. Anyone who has tried using SVG on Firefox knows that the code renders so slowly as to be almost unusable, and lacks support for a tremendous number of SVG features. On top of that Adobe's own staff were always the big force behind SVG, now that Adobe has pulled out of SVG development its safe to say that SVG has no future outside of the tiny community of inkscape users.

The only way I could see them removing SVG support would be if Adobe ever decided to open source the Flash player but even then I could imagine that this would not be a popular move as SVG is an open standard.


Aside from the video codecs--which are no doubt entangled in far too many patent issues for Adobe to publish the standards--Flash is just as open as SVG, and it's a shame that open standards pundits refuse to stop pretending otherwise. It makes them sound just as stupid as the HD-DVD evangelists who pretend that HD-DVD is any less proprietary than Blu-Ray, and its hard to convince people that standards-based web development is important when this kind of garbage keeps getting spewed out.

SVG will eventually get yanked from Firefox not because of sleazy deals between Adobe and the Mozilla foundation, but due to the W3C not being behind SVG, SVG not having enough developers, the majority of SVG content on the web being experimental projects, and lack of software support for animated SVG content.

Re:About SVG (0)

Anonymous Coward | more than 7 years ago | (#16795204)

I agree 100% with your post, but I just want to add another example of Mozilla pulling support for a format due to lack of use: MNG.

SVG is already dead as a Flash competitor. It still has some life as an open vector graphics format, but being XML-based, it produces horribly bloated files with a pretty lousy subset of features.

At some point in the future I expect the SVG support will be pulled for the same reason MNG support was pulled: no one actually uses it.

Re:About SVG (1)

starwed (735423) | more than 7 years ago | (#16797184)

There's already SVG on the web; wikipedia, for instance, uses it for displaying some types of images. So it's not like no one uses it.

only thousands of SVG images on popular sites (0)

Anonymous Coward | more than 7 years ago | (#16804994)

Wikipedia only has thousands of SVG images used in their pages, and only has millions of visitors daily.
And they're not even that special either.

Re:About SVG (0)

Anonymous Coward | more than 7 years ago | (#16805362)

I've never seen SVG images used on Wikipedia. I have seen PNG images created based on SVG images on Wikipedia, but that hardly counts, since they already had to convert it from one format to another that people can actually use.

Re:About SVG (0)

Anonymous Coward | more than 7 years ago | (#16795414)

I fear you're right and that is unfortunate because I'm never running flash bytecode, I don't run javascript from the web and even have my doubts about exslt.

Then again, XML is a good interchange format, meaning SVG may be preserved as a way of converting to/from proprietry Macrodobe and MSFT formats. I wonder if SVG could be remapped to a less verbose serialization format like YAML or JSON?

Re:About SVG (1)

jeff_schiller (877821) | more than 7 years ago | (#16798166)

> now that Adobe has pulled out of SVG development

Adobe Labs [adobe.com] still has some stake in SVG.

> its safe to say that SVG has no future outside of the tiny community of inkscape users.

All major browser manufacturers have plans for SVG at the moment, even IE has plans to eventually include SVG.

> the majority of SVG content on the web being experimental projects

Yeah, those experimental projects like Google Maps [codedread.com] and Microsoft Live Local [codedread.com] and Dojo [kylescholz.com]...

And for those who cite that SVG is "bloated" because it's XML, maybe you haven't heard of something called "compression"...

Re:About SVG (1)

BZ (40346) | more than 7 years ago | (#16799966)

> And for those who cite that SVG is "bloated" because it's XML, maybe you haven't heard of > something called "compression"...

Compression doesn't help with the bloat caused by having to maintain a DOM.

Even if you take the SVG Tiny route and not have a DOM, you have to _parse_ said XML. There are libraries for this, but efficient it is not.

Re:About SVG (0)

Anonymous Coward | more than 7 years ago | (#16804814)

IT is about delivering power, flexibility and efficiency to the developer and more importantly the end user. Something SVG does pretty well.
effiency in CPU cycles is secondary.

Re:About SVG (2, Informative)

NoMoreNicksLeft (516230) | more than 7 years ago | (#16798554)

I can open up an .swf in notepad and see the source?

I can inline flash elements in my (x)html page?

I'm allowed to write my own viewer for it?

BTW... Konqueror has good support for non-animated/non-scripted SVG already. Soon, it will fix those flaws as well. Webkit has about the same level of support, and there's a committment to make SVG a first-class image format for pages. Opera's support is stellar, including the animation/scripting parts. And Firefox isn't too shabby either.

As far as I know, that's all 4 major web browsers, and all those others that are based on their engines. I doubt SVG is going anywhere, except up. Die flash, die.

Re:About SVG (1)

supabeast! (84658) | more than 7 years ago | (#16802924)

I can open up an .swf in notepad and see the source?


No, but that question is irrelevant for the vast majority of end-users. Anything complex enough to be worth rendering in SVG isn't going to be something that there's any reason to look at the source for, aside from satisfying the personal curiosity of people with nothing better to do.

I can inline flash elements in my (x)html page?


No, but again, why does it matter if you can? Again, this might be a cute idea for a hobbyist, but not for someone with something important to do.

I'm allowed to write my own viewer for it?


Sure. But for some odd reason, it seems like all the capable programmers have better things to do.

Konqueror has good support for non-animated/non-scripted SVG already...Opera...

Again, irrelevant. Neither Opera nor Konqueror have a large enough user base to be relevant to people developing animation for the web.

And Firefox isn't too shabby either.

Now you're just spouting nonsense. Firefox's rendering performance regarding SVG is pathetic at best. It might work for a tiny graphic here and there, but anything complex or containing more than a few elements grinds away slowly on the fastest machines.

I doubt SVG is going anywhere, except up. Die flash, die.

Given that Adobe was the only hope SVG ever had of going anywhere, there's nothing to make SVG go anywhere. Flash FTW.

Re:About SVG (0)

Anonymous Coward | more than 7 years ago | (#16804612)

About any mobile phone does SVG, Sony PS2 games use it, even printers using SVG. Even Microsoft uses it on some of their most popular sites. And there are many sites already using it, only rasterizing on the server before sending it off to the browser.
Maybe you're just trying to ignore. For all the others, see http://svg.startpagina.nl/ [startpagina.nl]

SVG just keeps growing (0)

Anonymous Coward | more than 7 years ago | (#16805220)

>> I can open up an .swf in notepad and see the source?

>No, but that question is irrelevant for the vast majority of end-users.

- the more power developers have at hand, the better the products for end-users get
- yeah right, like nobody copies ingredients from around the web into their own website

>>I can inline flash elements in my (x)html page?

>No, but again, why does it matter if you can?

accessibility, context, semantics. The web is more and more not (only) about the page you call your endproduct, but by how that information is found and repurposed.

>>I'm allowed to write my own viewer for it?

>Sure. But for some odd reason, it seems like all the capable programmers have better things to do.

Not odd at all, capable programmers are smart enough to not throw away their time at something that the owner can change whenever it feels like. And i'd make sure to contact a lawyer if you decide to do it anyway.

>>Konqueror has good support for non-animated/non-scripted SVG already...Opera...

>Neither Opera nor Konqueror have a large enough user base to be relevant to people developing animation for the web.

There's a thing called the mobile web, growing explosively, and Opera has a huge marketshare.

>>And Firefox isn't too shabby either.

>grinds away slowly on the fastest machines.

There's a little wait on superduper complex content, but otherwise it's fine.
And my laptop is slower than the cheapest laptop in stores now.

>>I doubt SVG is going anywhere, except up. Die flash, die.

>Given that Adobe was the only hope SVG ever had of going anywhere, there's nothing to make SVG go anywhere

Wrong information, wrong conclusion. Maybe take a look at http://svg.startpagina.nl/ [startpagina.nl] to see where SVG is and is going.

not so sure about SVG (3, Informative)

sootman (158191) | more than 7 years ago | (#16794970)

I'm a huge fan of SVG. Not because it's a replacement for Flash, but because it's just XML, which means you can create data-based SVG images "out of thin air" with PHP or the scripting language of your choice. But now that Adobe has bought Macromedia (and with it, Flash) it looks like they're going to give up on SVG. [adobe.com] I'm sure their apps will let you save as SVG, but they're going to quit supporting the viewer on 1/1/2008. And theirs was the dominant viewer. Mozilla has native support, and Safari is getting it, but that's nowhere near the adoption rate of MSIE or Flash.*

I was really hoping that they'd go the other way--that with the purchase of Macromedia, they'd roll SVG support into the hugely popular Flash plug-in. I wish I were wrong, but my guess is that Adobe, just like MS or anyone else, would rather back a proprietary solution (that they own) than an open one.

* and, the funny thing is, the MSIE/Adobe combination--on Mac and Windows--was the best. You could print a page with lots of embedded SVG images, and it worked! Safari with Adobe's plugin, or Mozilla with the plugin or natively, would print each image on a separate page, if at all. (Though I haven't tested FF 2.0 yet.) But MSIE/Adobe printed just as you saw on screen.

Re:not so sure about SVG (1)

drgonzo59 (747139) | more than 7 years ago | (#16796084)

I am with you on SVG. My take on it is that it is the browser's job to implement SVG well and it will take off from there. I have tried creating SVG-only pages with Inkscape and it turned out pretty well...

Re:not so sure about SVG (1)

curunir (98273) | more than 7 years ago | (#16797146)

...but because it's just XML, which means you can create data-based SVG images "out of thin air" with PHP or the scripting language of your choice.
This was never the reason why SVG was promising. There have been imagine manipulation libraries available to scripting languages for a long time. I remember using GD in Perl to create GIF images "out of thin air" as you put it. That was in 1996.

The strength of SVG is that it's vector-based. This allows developers to produce images that can be resized on-the-fly by the user's browser with no loss in image quality. This becomes a particularly good thing when you start to design CSS-based webpages that make no assumptions about the user's monitor resolution. So long as dimensions of elements are specified as percentages rather than pixels, SVG allows a webpage to look great at everything from 800x600 to the insanely high resolutions that monitors/video cards are capable of these days. And it's not just for webpages. SVG makes a great technology for icons in any UI. OS X already has SVG rendering built into Aqua and I believe that there are Linux window managers that have also integrated it into their offering.

SVG is the key for enabling us to use higher resolutions without having to have 20/10 vision to see everything that's based around the concept of a pixel.

Re:not so sure about SVG (1)

BZ (40346) | more than 7 years ago | (#16799940)

The problem with SVG is that the working group is more interested in giving cell-phone makers a Flash competitor standard than in actually creating a vector graphics standard. This is why SVG is getting things like network socket APIs while fundamental problems with the "vector graphics" part are ignored.

What javaScript needs (1)

sproketboy (608031) | more than 7 years ago | (#16796032)

What javaScript needs is optional strong typing and name spaces. If it is to move forward for ajax applications.

Re:What javaScript needs (1)

mad.frog (525085) | more than 7 years ago | (#16796590)

What javaScript needs is optional strong typing and name spaces.

It's getting that, and a bunch of other cool stuff, in the ECMAScript 4 version that Tamarin will implement.

To see the current working proposals for ECMA for, go here: http://developer.mozilla.org/es4/ [mozilla.org]

Re:What javaScript needs (1)

sproketboy (608031) | more than 7 years ago | (#16799574)

Thanks for the link. Yeah that's nice and all but if it's not going to be supported by M$ it's all moot no?

One step at a time (0)

Anonymous Coward | more than 7 years ago | (#16796660)

How about they talk about how to fix their little flash plug-in from going crazy in Mozilla/Firefox before going on to the bigger stuff.

- Wolf Bearclaw

good news and bad news (1)

Heppelld0 (1003848) | more than 7 years ago | (#16797630)

just thought i'd state the obvious...

good points are that if the co-operation meant better compatability, (if i made a site in go-live then it would definately work in firefox, or firefox could be made to adapt to go-live standard content) then i'd be happy!

bad news could be that firefox becomes closed source, and this could be a precursor to a buy-out. first, adobe are tempting the execs, getting friendly, and showing them what substantial funding culminates to... then deciding that, somehow, a coroporate merging would be a good idea...

just a thought...

Re:good news and bad news (1)

TobascoKid (82629) | more than 7 years ago | (#16798790)

How would firefox ever become closed source? It's already been released under open source licences, one of which being the GPL, so it would be pretty much impossible to close (as anyone could just start their own fork from the already released codebase, see iceweasal for an example).

And Adobe are open sourceing Tamarin - so again, no closed source. This is not a trap.

Adobe Firefox! (-1, Troll)

nilbog (732352) | more than 7 years ago | (#16799558)

Oh please oh please can we have Adobe Firefox? I'm just thinking of some awesome features:

* Loads in just a few minutes!
* One year Universal Binary Delay for Macs
* Opening multiple windows brings computer to a crawl
* Free (with a google search for "F1r3f0x s3rialz")
* Various Features cause other Adobe applications to load for no reason. Think: Imageready for everything.
* Memory Resident version updater that bugs you every time you boot up

I'm excited for adobe's entry into the browser market.

Re:Adobe Firefox! (0)

Anonymous Coward | more than 7 years ago | (#16800184)

You're confusing Reader with Flash.
- One is slow, the other is pretty streamlined.
- One sucks, and the other sucks... less.

I'm all for this integration and, strategically speaking, I think it's pretty cool for Macrodobe. The AVM has to be one of Adobe's most advanced pieces of software and I think it's great that they're contributing it to the noble Firefox cause.

Update to Story (0)

Anonymous Coward | more than 7 years ago | (#16802942)

She was also found in possession of "D&D 3E - WotC - Manual of the Planes" and "Generic - Dungeon Floorplans".

Said a Scotland Yard Spokesman, "It seems clear she intended to open a portal to another dimension, and then attack this Dungeon. As it is generic, we are unsure of its exact location. We are looking for her accomplices: a dwarf with a +2 axe, which we think is some kind of axe, and Ian McKellen."

The Spokeseman said the force is concerned about other such plots, noting "there may be as many as 1,600 of these plots in progress at any time in the UK. They increase during weekends, and on school holidays. Young males seem to be at most at risk, but this subject was clearly a woman."
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...