if they had just changed the name and maybe the colors, problem solved - they would not have been shut down, and no users would have left.
I wonder if they still can't do that. Register a second company and have Scrabuous transfer all assets to it (including the registered users). Then re-release the game with a new name/board.
The cost of localizing everything is not inconsequential. You can't just run it through a translator and go and you still have to do acceptance testing on the localized version. The number of German or Itallian consumers is small compared to those who use English and the price reflects the marginal production costs per unit.
It's really odd then that I pay the same price in Europe for a non-localized version, isn't it.
The proven existence of intelligent extraterrestrial life will have a profound effect on a lot of people's core religious beliefs. That alone will have a major effect on society and it might just turn a few people away from their outdated superstitious beliefs. I consider that a tangible benefit.
Sure, finding alien life will have a lot of impact. The thing is SETI won't do that, at least as far as basic physics and math is concerned.
But of course, it may end up replacing out outdated superstitious beliefs, and replacing them with more modern superstitious beliefs, such as trying to catch alien radio on our satelites. The parallels between doing this, and an old-school prayer to God are quite ironic.
This Mohave thing looks like a facelift making the product less microsoftish and more Web 2.0/Apple inclined. It may work with people who got seducted with a Macbook if they cash in good press, enough ads and TV spots.
You're right, they are taking hints from Apple's marketing, but I really think they shouldn't. Microsoft is in a very different position than Apple. The Apple and Microsoft user demographic is completely differently structured. Apple has full control over the end product, while Microsoft provides only a piece of the puzzle (the OS).
Truth is, those companies are specialized to work well in their own market segment and either one imitating the other would fail miserably, as we're about to see here with the Mojave experiment.
1. It wrecks the illusion that Microsoft believes "Vista is the most successful Windows release ever". Have you seen them talk about Vista in public? They cite sales statistics and call it their most well received release ever. Why then do that campaign in the first place, and that late into the cycle?
2. Microsoft underestimated the power of technical users forming the opinion of their less technical friends, clients, family. The marketing of Vista (the "wow" begins now and so on) was targeted to the non-technical folks, while ignoring to address the concerns raised by the more technical people they communicate with on a daily basis. This campaign fails in that as well, so it'll have a very minimal effect on Vista's PR.
what if an unverifiable, untraceable voice announces in your ear "rob the bank or I shoot your wife", what would you do?
this is damn scary, where is my magneto helmet?
So someone is about to shoot your wife, and you're looking for a helmet? You set your priorities right, sir:)
Let's be serious for a moment: you can send threats via prepaid cellphone just as well, and you can torture a prisoner with conventional speakers, also just as well.
It's a fancy new device, but I don't see apocalypse coming:)
This is not AVG doing this, it is the AVG IE toolbar. And since this is running in the IE context it is debatable if it should not use the IE user agent.
What is debatable, is why the toolbar must scan all results for each user. A site is either malicious or it's not, such site probes must be done centrally and kept in a shared database.
AVG instead decided to save themselves some effort and cost of doing this centrally, and incur the cost on their clients, and on the site owners who are unfortunate (heh...) to be present in Google's search results.
If you use Firefox or disable the toolbar it is a non issue. The issue to me is I can't figure out how to install AVG without this toolbar, or how to remove it.
So I guess CmdrTaco should just disable his toolbar and it's a non issue.. Oh, right. The issue is with the site owners as much as, if not more, than AVG's users.
Put simply, the majority of code simply doesn't parallelize well. You can break out a few major portions of it to run as their own threads, but for the most part, programs either sit around and wait for the user, or sit around and wait for hardware resources.
Within that, only those programs that wait for a particular hardware resource - CPU time - Even have the potential to benefit from more cores... And while a lot of those might split well into a few threads, most will not scale (without a complete rewrite to chose entirely different algorithms - If they even exist to accomplish the intended purpose) to more than a handful of cores.
As a software engineer you should know that "most code doesn't parallelize" is very different from "most of the code's runtime can't parallelize", as code size and code runtime are substantially different things.
Look at most CPU intensive tasks today and you'll notice they all parallelize very well: archiving/extracting, encoding/decoding (video, audio), 2D and 3D GUI/graphics/animations rendering (not just for games anymore!), indexing and searching indexes, databases in general, and last but not least, image/video and voice recognition.
So, while your very high-level task is sequential, the *services* it calls or implicitly uses (like GUI rendering), and the smaller tasks it performs, actually would make a pretty good use of as many cores as you can throw at them.
This is good news for software engineers like you and me, as we can write mostly serial code and isolate slow tasks into isolated routines that we write once and reuse many times.
Raytracing doesn't mimic how real world works. In fact it does exactly the opposite of what happens in real world. In real world you have bazillions of light particles, doubling also as waves, shoot out of many area light sources and bounce/be absorbed by objects around them.
Whatever photons end up hitting your retina, is what you see.
Raytracing instead shoots a ray out of your (virtual) retina straight forward to the scene and may refract/reflect off objects, until it's "absorbed" (means, hits a surface where refraction/reflection isn't calculated).
Rendering a single frame of 3D as it is in the "real world" (with just a fraction of the rays) would mean days on even the fastest hardware out there.
What raytracing gives you is sharp reflections, refractions and shadows, while introducing a bunch of other limitations on the rendering that rasterization doesn't have. It also can't do soft shadows, reflections, refractions, efficiently, nor subsurface scattering, or radiosity.
Best models for rendering in the future will likely be hybrid models similar to what is now used in professional renderers by movie studios. But then again, it's a game, who cares about mathematicaly accurate reflections, when you can fake it close enough with reflection/refraction maps in a fraction of the processing time.
Silverlight doesn't support any of the 3D subsystem of.NET's WPF. It's 2D only, and software only.
For Flash, there are some fairly advanced 3D engines like PaperVision3D, which comes complete with such features like cell shaders, bumping and reflection map effects, rich material and scene handling API-s, support for 3DS and Collada objects and animations and so on.
What does Silverlight have to compete with this? Nothing. Maybe one day Silverlight will outdo Flash, and I'll gladly use it's suitable for a scenario. Right now, Flash beats it in almost all categories, including, yes, 3D.
I'm reading through the comments here and I can't believe my eyes. Boy, are you bitter, or what...
The features IE8 implements are a direct answer to what most users on Slashdot I've seen whine for years on an on, and still there's barely few mildly positive responses here, it's just so sad (for Slashdot).
Let me list a fraction of the improvements of IE8, should it be too hard for you to RTFA-s:
- Much improved compliance with the CSS 2.1 standards, compliance with certain most requested CSS3 features. This includes, but not limited to features such as display:inline-table,:after,:before, content attribute, counter-reset / counter-increment, box-sizing (implemented as -ms-box-sizing, similar to -moz-box-sizing as it's not finalized in CSS3), fixes on the p/div handling, CSS outline, improvements to text orientation rendering,
- Data URI support would dramatically simplify dynamic content generation in some instances, and improve the performance on pages with many small images (you can embed those images in the HTML and save yourself some 10-20 additional HTTP requests).
- More complete support for the CSS attributes related to page printing, such as @page, left/right/first page selectors, page-break-inside, widows, orphans properties.
- Kick-ass development and debugging tools that rival FireBug for Firefox (honestly, check the white-paper). If you're a web developer, you're probably using FireBug intensively, now you can debug with the same ease on IE.
- Hooks for AJAX navigation (I had to implement JS navigation on a project as recently as a week ago, and I know this will save me quite some time in the future, if the other browsers follow suit), DOM Storage (super-cookies:) ) that allow much richer offline storage, and combine this with ability to detect if the network is down/offline or not, and let your JS handle the situation! XHR has timeout now as well.
- CSS selectors API exposed to JS. Do you have any idea how *important* that is? Look at any popular JS library today: Prototype, jQuery, MooTools. They all *emulate* this feature. Some browsers, are starting to implement this, and now that IE is among them, those JS libraries can act as a simple proxy to the native Selectors API, and thus deliver substantial performance boost to pages doing lots of selections.
- 6 connections per host, versus 2. Before you start complaining how this will overload some servers: IE will start with 2 connections, and if it detects the connection is speedy, it'll build up to 6 dynamically. This means if you're being Slashdotted, for example, IE will detect this and keep connections 2 at a time.
- OBJECT tag was boosted to support all MIME types, using standard markup, the way other browsers handle it. That includes images.
- ActiveX plugins can now easily hook to an element namespace and provide rendering services, for example MathML, SVG etc.
- Cross-domain messaging and requests! This will make certain (safe!) application a *lot* easier. Currently the only workaround to safe cross-domain communication is a hack involving multiple iframes and hash manipulation. No more, this a really forward-looking of Microsoft to implement, hopefully the other browsers follow-suit.
- Sane versioning model, so if your site breaks in IE8 you can request IE7 mode via simple meta tag. The default would be the most compliant mode (as covered on a previous article).
- I've heard lots of whining here on Slashdot in the past about the circular memory 'leak' IE JS had. Now this is fixed. It's not as trivial as you might thing it is, and IE JS doesn't suffer alone from this problem (popular languages like PHP for example exhibit the same issue). A new garbage collector was implemented to fix this.
- Performance improvements to the CSS/HTML/JS subsystem will deliver speedier browsing without expected compatibility issues.
When IE8 is pushed out and it breaks a bunch of non-conforming non-tagged pages built for IE7 and IE6, there will be much hell raising to be had.
No one will raise hell because they only have to add a single meta tag to fix their broken sites.
The difficulty with IE7 was that the updated engine had unpredictable and unintended effects on certain sites, which had to be debugged, special cases added, code changed, tested, and so on.
If someone would rather bitch for days, instead of spending the 10 mins or so to add a harmless meta tag to his broken site, then well, web visitors should complain to that site's developers, not to Microsoft.
With a number of originally-for-Linux apps having been ported to OS X, without apparently calling for any overwhelming expense, why should Adobe's stuff, all of which runs on OS X, take much effort to port to Linux?
OSX has a fully features POSIX layer (what Linux apps use), but Linux has no Carbon/Cocoa layer, which is what OSX apps use.
In other words, because you can run some DOS command lines in Windows, doesn't mean it's equally easy to run some Windows GUI apps in DOS.
Up until now, Adobe hasn't done much in terms of porting its applications to Linux,...only.... Flash.... the company has announced a Linux port of AIR, its web application development software...
Wow:)... Few corrections:
1) Flex Builder has had a public alpha for Linux for some time now.
4) Adobe AIR isn't a web application development environment of any sort... that's completley messed up. It's the runtime component of a connected desktop app platform that supports HTML/CSS/JS/PDF/Flash content.
5) Macromedia (now part of Adobe) has made attempts to commercialize Dreamweaver/Flash/Freehand on Linux before utilizing Wine-compatible releases, but there was no enough demand to pay the bills, so the project was canned. I have the feeling they'll be trying this with selected Adobe CS applications again within 24 months, but it'll be expensive, so the market should show enough demand, and put their money where their mouth is, this time.
If the bots are stalling for time, it's quite likely someone's home-grown version of Mechanical Turk distributed "human" task service, similar to the one by Amazon.
The image is put on queue and, say, a good number of, say, overseas employees... are getting the image and need to fill back in the solution as plain text. In the mean time the bot is "reading the manual".
When the bot gets the answer in time, it submits the form and there we go, account.
Come on. You really think Microsoft wants to increase the vulnerability of old versions of Office (which are still the vast majority in corporate America). This not only makes their software looks bad, it increases the amount of work they have to do to support the older versions (yes, they still support Office 2003). You don't sell new cars by convincing people the last model was rubbish. I think your tin-foil hat fits a little to tight.
Let me break your statement in pieces:
- that would increase the vulnerability of old Office - the majority of corporate America is stuck on old Office - you don't sell old cars by convincing old ones are rubbish
You know, have you seen those white-papers by Microsoft comparing XP and Vista and trying to put XP-s reliability and security in bad light?
Or have you seen those ads where Microsoft rendered people using old versions of office as... dinosaur-mask wearing suits?
If the majority of corporate America uses the old Office, then the only way for Microsoft to turn in profit would be to somehow convince them this is not good for them anymore, and upgrade. You're just going against yourself there.
One may wonder, why release the documentation now?
If you read Joel's blog you'll see the formats are very old, and consist primarily of C-structs dumped to OLE objects, dumped directly to what we see as an XLS, DOC and so on files.
There's almost no parsing/validation at load time.
Having this in a well laid documentation may reveal quite a lot of security issues with the old binary formats, which could lead to a wave of exploits. Exploits that won't work on Microsoft's new XML Office formats.
So while I'm not a conspiracy nut, I do believe one of Microsoft's goals here are to assist the process of those binary formats becoming obsolete, to drive Office 2007/2008 adoption.
I got the real-world list of issues from a magical place, in order of priority:
1. It's not as common as a preinstalled OS with OEMs. 2. It doesn't run Windows software (well enough). 3. It doesn't look and function exactly as Windows. 4. It doesn't work with all hardware that Windows works with. ... ... ... ... 823. It's free, so people perceive it as inferior. ... ...
While you're asking for it to be "faster", other people are asking for a smaller memory footprint.. considering that most performance issues in a browser are related to caching, they can't please all the users all the time.
Actually, the perceived performance issues of Firefox mostly stem from the fact it's a single-threaded architecture running on a JavaScript+XML interpreter (XULRunner).
Extensions, which basically "patch" themselves into this single-threaded synchronous engine, often exacerbate the problem too.
All XUL applications seem to share this slow response / performance problem, other popular ones exhibiting the same issue being Joost, Miro, SunBird.
However this issue is so deeply ingrained in XULRunner, that I hear misguided excuses all the time, such as "it's about the RAM cache / CPU usage balance", which, oddly enough, no other major browser suffers from (I use all on a daily basis as a developer myself).
About when we'll see improvements: most likely starting with Firefox 4, which is to completely replace the current JS engine, SpiderMonkey, with the one in Flash 9 (codenamed Tamarin), which compiles to machine code before execution, instead of being interpreted from opcodes.
We'll hopefully see some threading too (one thread for the main UI and one per tab at least), although the lead Mozilla developers have some quite irrational fears of multi-threaded architectures.
If it became part of the browser, 3 things would happen: Idiots would scream and cry about being forced to use it, it would integrate better making it more effective, and vulnerabilities like the one referenced here would be a non-issue for a much larger percentage of the user base.
Seriously, running every script a page stuffs into a browser should not be the default, and it should not take an extension to fix it.
No, actually scripts are supposed to be safe and run in a sandbox. There are plenty of legitimate sites where you'd enable the scripts only to find out the site was hacked and used to spread malware.
Throwing hundreds of prompts at the user at every step of the browsing process are not the solution you're looking for, in fact, I'm surprised this what the Slashdot crowd supports.
Let's put things in a different context:
If UAC became part of Windows Vista, 3 things would happen: Idiots would scream and cry about being forced to use it, it would integrate better making it more effective, and vulnerabilities like the one referenced here would be a non-issue for a much larger percentage of the user base.
Seriously, running every script a page stuffs into a browser should not be the default, and it should not take an extension to fix it.
This is what you suggest after all, UAC for browsers. Be gone popup ads, and welcome the endless warnings and security dialogs...
They should be happy the most popular browsers don't apply their recommendation and don't get the DTD even once. Because *then* they'd see hell.
DTD-s would be part of of the normal web page cache, and we know there are plenty and plenty of scenarios demanding that cache be turned off for limited or extended periods of time. Development is just one of those.
I find it discouraging that at the slow speed W3C produce and finalize their recommendations, they are still full of badly designed gems, such as the DTD being downloadable from a single URL somewhere on some single site (not to get started on the DTD syntax itself).
They need help, and I'm glad WHATWG are there to help those guys with making HTML5 reality.
Re:"How will you use XML in years to come?"
on
The Future of XML
·
· Score: 2, Interesting
Sparingly. JSON is just plain better, and doesn't inflict an enterprisey mindset on anyone that tries to use it.
While I understand your pain, XML is still a very nice *markup* language, for marking up documents and simple content trees.
Can you imagine HTML / XHTML implemented as JSON? I doubt that.
The fault with people here lies in XML abuse, namely SOAP-like XML API-s and using XML for everything, where binary formats, or more compact and simpler formats, like JSON, do better.
In case anybody is interest *why* Vista pre-SP1 seemed so much slower copying files than XP, and why post-SP1 for the most part fixes it, you should check out Mark Russinovich's blog post on the matter.
It's a very interesting read.
It is, but let me summarize it for a sad realization:
"In XP, we just issued 64kb read/writes via the standard API-s and used Cache Manager.
In Vista, a team saw a problem than no one before saw, and wrote a dedicated, big, complex engine, the File Copy Engine (tm) that, among other things, doesn't use caching in most instances, because it might take extra 128kb of RAM or so, and This Was Bad.
Improvements in SP1: we went back to XP's engine, with some tweaks."
Do you remember that previous case of a Microsoft programmer spending an year on a minor tweak of Vista's Start Menu? It was not the exception, guys. Sad.
Well, I think they're slowly getting their act together under Sinofsky's leadership, though.
Slashdot Mirror
Both "practical" and "jetpack" may need quotation marks, however
So essentially this article should be titled: "Practical" "Jetpack" Available "Soon".
But it costs $100k, so I guess it's not really "available" to most normal people either. So it becomes: "Practical" "Jetpack" "Available" "Soon".
That's the kind of stuff I come here to read :)!
if they had just changed the name and maybe the colors, problem solved - they would not have been shut down, and no users would have left.
I wonder if they still can't do that. Register a second company and have Scrabuous transfer all assets to it (including the registered users). Then re-release the game with a new name/board.
The cost of localizing everything is not inconsequential. You can't just run it through a translator and go and you still have to do acceptance testing on the localized version. The number of German or Itallian consumers is small compared to those who use English and the price reflects the marginal production costs per unit.
It's really odd then that I pay the same price in Europe for a non-localized version, isn't it.
The proven existence of intelligent extraterrestrial life will have a profound effect on a lot of people's core religious beliefs. That alone will have a major effect on society and it might just turn a few people away from their outdated superstitious beliefs. I consider that a tangible benefit.
Sure, finding alien life will have a lot of impact. The thing is SETI won't do that, at least as far as basic physics and math is concerned.
But of course, it may end up replacing out outdated superstitious beliefs, and replacing them with more modern superstitious beliefs, such as trying to catch alien radio on our satelites. The parallels between doing this, and an old-school prayer to God are quite ironic.
This Mohave thing looks like a facelift making the product less microsoftish and more Web 2.0/Apple inclined.
It may work with people who got seducted with a Macbook if they cash in good press, enough ads and TV spots.
You're right, they are taking hints from Apple's marketing, but I really think they shouldn't. Microsoft is in a very different position than Apple. The Apple and Microsoft user demographic is completely differently structured. Apple has full control over the end product, while Microsoft provides only a piece of the puzzle (the OS).
Truth is, those companies are specialized to work well in their own market segment and either one imitating the other would fail miserably, as we're about to see here with the Mojave experiment.
This campaign has two problems:
1. It wrecks the illusion that Microsoft believes "Vista is the most successful Windows release ever". Have you seen them talk about Vista in public? They cite sales statistics and call it their most well received release ever. Why then do that campaign in the first place, and that late into the cycle?
2. Microsoft underestimated the power of technical users forming the opinion of their less technical friends, clients, family. The marketing of Vista (the "wow" begins now and so on) was targeted to the non-technical folks, while ignoring to address the concerns raised by the more technical people they communicate with on a daily basis. This campaign fails in that as well, so it'll have a very minimal effect on Vista's PR.
1) Still opt-out style. Unless you add yourself to the list, you are fair game for callers
2) Still ineffective against pollsters, politicians, and fundraisers
It's better than nothing, but there are certainly ways to make it better.
I don't see how being forced to buy something by law means you give it a "glowing review", alas..
Another way to fight against unsolicited calls is to figure out who called you and take further actions that they are exposed, and possibly shut down.
what if an unverifiable, untraceable voice announces in your ear "rob the bank or I shoot your wife", what would you do?
this is damn scary, where is my magneto helmet?
So someone is about to shoot your wife, and you're looking for a helmet? You set your priorities right, sir :)
Let's be serious for a moment: you can send threats via prepaid cellphone just as well, and you can torture a prisoner with conventional speakers, also just as well.
It's a fancy new device, but I don't see apocalypse coming :)
This is not AVG doing this, it is the AVG IE toolbar. And since this is running in the IE context it is debatable if it should not use the IE user agent.
What is debatable, is why the toolbar must scan all results for each user. A site is either malicious or it's not, such site probes must be done centrally and kept in a shared database.
AVG instead decided to save themselves some effort and cost of doing this centrally, and incur the cost on their clients, and on the site owners who are unfortunate (heh...) to be present in Google's search results.
If you use Firefox or disable the toolbar it is a non issue. The issue to me is I can't figure out how to install AVG without this toolbar, or how to remove it.
So I guess CmdrTaco should just disable his toolbar and it's a non issue.. Oh, right. The issue is with the site owners as much as, if not more, than AVG's users.
As a software engineer, I wonder the same thing.
Put simply, the majority of code simply doesn't parallelize well. You can break out a few major portions of it to run as their own threads, but for the most part, programs either sit around and wait for the user, or sit around and wait for hardware resources.
Within that, only those programs that wait for a particular hardware resource - CPU time - Even have the potential to benefit from more cores... And while a lot of those might split well into a few threads, most will not scale (without a complete rewrite to chose entirely different algorithms - If they even exist to accomplish the intended purpose) to more than a handful of cores.
As a software engineer you should know that "most code doesn't parallelize" is very different from "most of the code's runtime can't parallelize", as code size and code runtime are substantially different things.
Look at most CPU intensive tasks today and you'll notice they all parallelize very well: archiving/extracting, encoding/decoding (video, audio), 2D and 3D GUI/graphics/animations rendering (not just for games anymore!), indexing and searching indexes, databases in general, and last but not least, image/video and voice recognition.
So, while your very high-level task is sequential, the *services* it calls or implicitly uses (like GUI rendering), and the smaller tasks it performs, actually would make a pretty good use of as many cores as you can throw at them.
This is good news for software engineers like you and me, as we can write mostly serial code and isolate slow tasks into isolated routines that we write once and reuse many times.
Ray tracing mimicks how real world works.
Raytracing doesn't mimic how real world works. In fact it does exactly the opposite of what happens in real world. In real world you have bazillions of light particles, doubling also as waves, shoot out of many area light sources and bounce/be absorbed by objects around them.
Whatever photons end up hitting your retina, is what you see.
Raytracing instead shoots a ray out of your (virtual) retina straight forward to the scene and may refract/reflect off objects, until it's "absorbed" (means, hits a surface where refraction/reflection isn't calculated).
Rendering a single frame of 3D as it is in the "real world" (with just a fraction of the rays) would mean days on even the fastest hardware out there.
What raytracing gives you is sharp reflections, refractions and shadows, while introducing a bunch of other limitations on the rendering that rasterization doesn't have. It also can't do soft shadows, reflections, refractions, efficiently, nor subsurface scattering, or radiosity.
Best models for rendering in the future will likely be hybrid models similar to what is now used in professional renderers by movie studios. But then again, it's a game, who cares about mathematicaly accurate reflections, when you can fake it close enough with reflection/refraction maps in a fraction of the processing time.
Because Flash can't do 3D.
.NET's WPF. It's 2D only, and software only.
:)
Silverlight doesn't support any of the 3D subsystem of
For Flash, there are some fairly advanced 3D engines like PaperVision3D, which comes complete with such features like cell shaders, bumping and reflection map effects, rich material and scene handling API-s, support for 3DS and Collada objects and animations and so on.
Demos here. Check the rhino and Earth demo too
What does Silverlight have to compete with this? Nothing. Maybe one day Silverlight will outdo Flash, and I'll gladly use it's suitable for a scenario. Right now, Flash beats it in almost all categories, including, yes, 3D.
I'm reading through the comments here and I can't believe my eyes. Boy, are you bitter, or what...
:after, :before, content attribute, counter-reset / counter-increment, box-sizing (implemented as -ms-box-sizing, similar to -moz-box-sizing as it's not finalized in CSS3), fixes on the p/div handling, CSS outline, improvements to text orientation rendering,
:) ) that allow much richer offline storage, and combine this with ability to detect if the network is down/offline or not, and let your JS handle the situation! XHR has timeout now as well.
The features IE8 implements are a direct answer to what most users on Slashdot I've seen whine for years on an on, and still there's barely few mildly positive responses here, it's just so sad (for Slashdot).
Let me list a fraction of the improvements of IE8, should it be too hard for you to RTFA-s:
- Much improved compliance with the CSS 2.1 standards, compliance with certain most requested CSS3 features. This includes, but not limited to features such as display:inline-table,
- Data URI support would dramatically simplify dynamic content generation in some instances, and improve the performance on pages with many small images (you can embed those images in the HTML and save yourself some 10-20 additional HTTP requests).
- More complete support for the CSS attributes related to page printing, such as @page, left/right/first page selectors, page-break-inside, widows, orphans properties.
- Kick-ass development and debugging tools that rival FireBug for Firefox (honestly, check the white-paper). If you're a web developer, you're probably using FireBug intensively, now you can debug with the same ease on IE.
- Hooks for AJAX navigation (I had to implement JS navigation on a project as recently as a week ago, and I know this will save me quite some time in the future, if the other browsers follow suit), DOM Storage (super-cookies
- CSS selectors API exposed to JS. Do you have any idea how *important* that is? Look at any popular JS library today: Prototype, jQuery, MooTools. They all *emulate* this feature. Some browsers, are starting to implement this, and now that IE is among them, those JS libraries can act as a simple proxy to the native Selectors API, and thus deliver substantial performance boost to pages doing lots of selections.
- 6 connections per host, versus 2. Before you start complaining how this will overload some servers: IE will start with 2 connections, and if it detects the connection is speedy, it'll build up to 6 dynamically. This means if you're being Slashdotted, for example, IE will detect this and keep connections 2 at a time.
- OBJECT tag was boosted to support all MIME types, using standard markup, the way other browsers handle it. That includes images.
- ActiveX plugins can now easily hook to an element namespace and provide rendering services, for example MathML, SVG etc.
- Cross-domain messaging and requests! This will make certain (safe!) application a *lot* easier. Currently the only workaround to safe cross-domain communication is a hack involving multiple iframes and hash manipulation. No more, this a really forward-looking of Microsoft to implement, hopefully the other browsers follow-suit.
- Sane versioning model, so if your site breaks in IE8 you can request IE7 mode via simple meta tag. The default would be the most compliant mode (as covered on a previous article).
- I've heard lots of whining here on Slashdot in the past about the circular memory 'leak' IE JS had. Now this is fixed. It's not as trivial as you might thing it is, and IE JS doesn't suffer alone from this problem (popular languages like PHP for example exhibit the same issue). A new garbage collector was implemented to fix this.
- Performance improvements to the CSS/HTML/JS subsystem will deliver speedier browsing without expected compatibility issues.
When IE8 is pushed out and it breaks a bunch of non-conforming non-tagged pages built for IE7 and IE6, there will be much hell raising to be had.
No one will raise hell because they only have to add a single meta tag to fix their broken sites.
The difficulty with IE7 was that the updated engine had unpredictable and unintended effects on certain sites, which had to be debugged, special cases added, code changed, tested, and so on.
If someone would rather bitch for days, instead of spending the 10 mins or so to add a harmless meta tag to his broken site, then well, web visitors should complain to that site's developers, not to Microsoft.
With a number of originally-for-Linux apps having been ported to OS X, without apparently calling for any overwhelming expense, why should Adobe's stuff, all of which runs on OS X, take much effort to port to Linux?
OSX has a fully features POSIX layer (what Linux apps use), but Linux has no Carbon/Cocoa layer, which is what OSX apps use.
In other words, because you can run some DOS command lines in Windows, doesn't mean it's equally easy to run some Windows GUI apps in DOS.
Up until now, Adobe hasn't done much in terms of porting its applications to Linux, ...only .... Flash. ... the company has announced a Linux port of AIR, its web application development software...
:)... Few corrections:
Wow
1) Flex Builder has had a public alpha for Linux for some time now.
2) There's Adobe Acrobat for Linux/Solaris/Unix
3) Most of the servers Adobe offers, like ColdFusion and Flash Media Streaming servers are available for Linux/Unix.
4) Adobe AIR isn't a web application development environment of any sort... that's completley messed up. It's the runtime component of a connected desktop app platform that supports HTML/CSS/JS/PDF/Flash content.
5) Macromedia (now part of Adobe) has made attempts to commercialize Dreamweaver/Flash/Freehand on Linux before utilizing Wine-compatible releases, but there was no enough demand to pay the bills, so the project was canned. I have the feeling they'll be trying this with selected Adobe CS applications again within 24 months, but it'll be expensive, so the market should show enough demand, and put their money where their mouth is, this time.
If the bots are stalling for time, it's quite likely someone's home-grown version of Mechanical Turk distributed "human" task service, similar to the one by Amazon.
The image is put on queue and, say, a good number of, say, overseas employees... are getting the image and need to fill back in the solution as plain text. In the mean time the bot is "reading the manual".
When the bot gets the answer in time, it submits the form and there we go, account.
Come on. You really think Microsoft wants to increase the vulnerability of old versions of Office (which are still the vast majority in corporate America). This not only makes their software looks bad, it increases the amount of work they have to do to support the older versions (yes, they still support Office 2003). You don't sell new cars by convincing people the last model was rubbish. I think your tin-foil hat fits a little to tight.
Let me break your statement in pieces:
- that would increase the vulnerability of old Office
- the majority of corporate America is stuck on old Office
- you don't sell old cars by convincing old ones are rubbish
You know, have you seen those white-papers by Microsoft comparing XP and Vista and trying to put XP-s reliability and security in bad light?
Or have you seen those ads where Microsoft rendered people using old versions of office as... dinosaur-mask wearing suits?
If the majority of corporate America uses the old Office, then the only way for Microsoft to turn in profit would be to somehow convince them this is not good for them anymore, and upgrade. You're just going against yourself there.
One may wonder, why release the documentation now?
If you read Joel's blog you'll see the formats are very old, and consist primarily of C-structs dumped to OLE objects, dumped directly to what we see as an XLS, DOC and so on files.
There's almost no parsing/validation at load time.
Having this in a well laid documentation may reveal quite a lot of security issues with the old binary formats, which could lead to a wave of exploits. Exploits that won't work on Microsoft's new XML Office formats.
So while I'm not a conspiracy nut, I do believe one of Microsoft's goals here are to assist the process of those binary formats becoming obsolete, to drive Office 2007/2008 adoption.
I got the real-world list of issues from a magical place, in order of priority:
...
...
...
...
...
...
1. It's not as common as a preinstalled OS with OEMs.
2. It doesn't run Windows software (well enough).
3. It doesn't look and function exactly as Windows.
4. It doesn't work with all hardware that Windows works with.
823. It's free, so people perceive it as inferior.
While you're asking for it to be "faster", other people are asking for a smaller memory footprint.. considering that most performance issues in a browser are related to caching, they can't please all the users all the time.
Actually, the perceived performance issues of Firefox mostly stem from the fact it's a single-threaded architecture running on a JavaScript+XML interpreter (XULRunner).
Extensions, which basically "patch" themselves into this single-threaded synchronous engine, often exacerbate the problem too.
All XUL applications seem to share this slow response / performance problem, other popular ones exhibiting the same issue being Joost, Miro, SunBird.
However this issue is so deeply ingrained in XULRunner, that I hear misguided excuses all the time, such as "it's about the RAM cache / CPU usage balance", which, oddly enough, no other major browser suffers from (I use all on a daily basis as a developer myself).
About when we'll see improvements: most likely starting with Firefox 4, which is to completely replace the current JS engine, SpiderMonkey, with the one in Flash 9 (codenamed Tamarin), which compiles to machine code before execution, instead of being interpreted from opcodes.
We'll hopefully see some threading too (one thread for the main UI and one per tab at least), although the lead Mozilla developers have some quite irrational fears of multi-threaded architectures.
If it became part of the browser, 3 things would happen: Idiots would scream and cry about being forced to use it, it would integrate better making it more effective, and vulnerabilities like the one referenced here would be a non-issue for a much larger percentage of the user base.
Seriously, running every script a page stuffs into a browser should not be the default, and it should not take an extension to fix it.
No, actually scripts are supposed to be safe and run in a sandbox. There are plenty of legitimate sites where you'd enable the scripts only to find out the site was hacked and used to spread malware.
Throwing hundreds of prompts at the user at every step of the browsing process are not the solution you're looking for, in fact, I'm surprised this what the Slashdot crowd supports.
Let's put things in a different context:
If UAC became part of Windows Vista, 3 things would happen: Idiots would scream and cry about being forced to use it, it would integrate better making it more effective, and vulnerabilities like the one referenced here would be a non-issue for a much larger percentage of the user base.
Seriously, running every script a page stuffs into a browser should not be the default, and it should not take an extension to fix it.
This is what you suggest after all, UAC for browsers. Be gone popup ads, and welcome the endless warnings and security dialogs...
They should be happy the most popular browsers don't apply their recommendation and don't get the DTD even once. Because *then* they'd see hell.
DTD-s would be part of of the normal web page cache, and we know there are plenty and plenty of scenarios demanding that cache be turned off for limited or extended periods of time. Development is just one of those.
I find it discouraging that at the slow speed W3C produce and finalize their recommendations, they are still full of badly designed gems, such as the DTD being downloadable from a single URL somewhere on some single site (not to get started on the DTD syntax itself).
They need help, and I'm glad WHATWG are there to help those guys with making HTML5 reality.
Sparingly. JSON is just plain better, and doesn't inflict an enterprisey mindset on anyone that tries to use it.
While I understand your pain, XML is still a very nice *markup* language, for marking up documents and simple content trees.
Can you imagine HTML / XHTML implemented as JSON? I doubt that.
The fault with people here lies in XML abuse, namely SOAP-like XML API-s and using XML for everything, where binary formats, or more compact and simpler formats, like JSON, do better.
In case anybody is interest *why* Vista pre-SP1 seemed so much slower copying files than XP, and why post-SP1 for the most part fixes it, you should check out Mark Russinovich's blog post on the matter.
It's a very interesting read.
It is, but let me summarize it for a sad realization:
"In XP, we just issued 64kb read/writes via the standard API-s and used Cache Manager.
In Vista, a team saw a problem than no one before saw, and wrote a dedicated, big, complex engine, the File Copy Engine (tm) that, among other things, doesn't use caching in most instances, because it might take extra 128kb of RAM or so, and This Was Bad.
Improvements in SP1: we went back to XP's engine, with some tweaks."
Do you remember that previous case of a Microsoft programmer spending an year on a minor tweak of Vista's Start Menu? It was not the exception, guys. Sad.
Well, I think they're slowly getting their act together under Sinofsky's leadership, though.