I understand that this is the case now. I am pointing out why it failed in the first place -- note that I've used past tense in pretty much my entire post.
Maybe so -- but they certainly were not "tired" when they came out, at least. The Seinfeld ad was just pointless when it came out -- OK, I chuckled, but I still want those 30 seconds of my life back.
and full of lies ("Only Macs are able to work with Japanese digital cameras!!"
I don't believe that was the point -- more that they do so out of the box, easily, with no issues. At the time, the same couldn't be said for PCs -- at the very least, you'd have to install the software that came with the camera. Since Microsoft has no control over that software, it's entirely hit or miss whether it's any good.
Since they never explicitly stated anything like that, I can only assume that the other "lies" and "bullshit" is your own misinterpretation, and not anything actually in the ad.
Disclaimer: I don't use either, entirely. I run Linux on PC hardware, and occasionally boot XP for games.
Why would a file start to download simply due to a user highlighting it (aka Select)?
Not quite. Workflow is:
- User hits "browse"
- User selects file (or more than one)
- User clicks "Select", or "OK", or whatever the "confirm this dialog" button is
- We start uploading the file.
So, if by "confirmation button" you mean some arbitrary Submit button, you're right, we don't wait for that. But it's not as though we can immediately grab the file just because you're looking at it in your browse window. You can always cancel that window, and we'll never know what you clicked.
The point is, these are large-ish files, and a lot of them (5-10) -- so especially over slower links, we want to make it as quick as possible to select which ones, and we want the upload to start as early as possible -- not before.
THanks for giving another reason why Flash is a buggy, insecure POS.
No more so, in this case, than the browser itself. Consider: Any data you type into an input field, whether you submit or not, could easily be intercepted by a script and sent back via AJAX. Before XHR, it could have been done with a hidden iframe.
The browser has quite a lot more potential control over uploads -- Konqueror prompts me directly immediately before any file is sent. But what is stopping a page from intercepting a file upload field's onChange event, and submitting the form? (I haven't checked -- maybe this has been addressed.)
But this isn't a point against Flash, it's a point against Flash being closed-source. See, most users would much rather have the behavior we've got now. If you'd rather have the uploads be more explicit, an open source flash would let you write that capability.
and the method used before by the extensions isn't supported anymore.
So, was there once an extension for multi-file upload?
But in Linux - in most advanced desktop distro Ubuntu - the easiest method... right - e-mail.
Mostly because you already know how. Arguably, there are many alternatives, some quite easy.
Setting up (not installed by default) FTPd/OpenSSH/Avahi - is not something I can advise to end users to install setup by default.
FTP would be a poor choice, anyway, for many reasons.
writing off everything on "security via obscurity". As if sending confidential data over 3rd party is safer than sending them over LAN...
Well, if you're on a wireless network, and the 3rd party at least uses SSL, then yes, it is more secure.
And yes, it should be easy -- however, kludging together something like FTP/Avahi isn't really a great idea.
Avahi, by the way, comes installed out of the box, doesn't it? And setting up openssh is pretty much just "sudo apt-get install openssh-server", and you're done -- the hardest part would be finding the current IP.
One of the big reasons no one had any interest in minix is the incredible performance hit the design entails.
At what point?
I think the main reason no one had an interest in Minix was the cost, and the restrictive licensing. Linus admitted that he never expected Linux to be much more than a stopgap until GNU/HURD was released -- except that HURD took too long to get any kind of release out the door, so Linux already had adoption at that point.
The best argument at the time was: You could spend the money and buy Minix, and install it. And then install the source code, and download a number of patches needed to get something approximating a modern OS, recompile, and reinstall.
Or you could spend that same money on a faster computer (a 386), and get Linux for free. Linux could do everything Minix could, and it already ran in native 32-bit mode (which Minix needed patches for).
In fact, that's one of several other ways Minix took performance hits -- ways that I'd call bad design. The filesystem, for example -- Minix has a non-threaded filesystem; Linux had a threaded filesystem.
Unfortunately, there are a great many things Flash does for which there are no alternatives, open or otherwise.
Let me give you a recent, stupid example: We want to let users upload a bunch of things at once. We have three options:
1: Build something using multiple file upload fields. (This could be done elegantly -- by hiding one as soon as it's set, and generating a new one.) In other words, we force the user to select each file individually, and click browse again -- and the files can't start uploading until they've all been selected.
2: Accept zipfiles. Extra work for us (admittedly not much), and extra work for them.
3: Use Flash. Not only can they select more than one file in the open dialog (ctrl+click, shift+click, ctrl+a, etc), but as soon as they select one, we can start uploading it.
I want to use open alternatives. I hate Flash more than... I'm not a very hateful person, but Flash makes me homicidal. But even something as simple as that, there's an advantage to using Flash.
Also Kopete is cross-platform these days with binaries on Solaris, BSD, Mac, Windows and Linux.
So what's the problem with using Kopete in GNOME again?
"Kopete is for KDE" is like saying "Firefox is for GNOME". To be fair, Firefox isn't as tied to GNOME, and could be ported to Qt, whereas Kopete almost certainly links in KDElibs -- but that's no reason you can't use it, unless you're severely low on RAM.
Sure, it's not the best Windows port. And sure, if you were going to criticize it, the default response would be "It's better on a Mac." But it does exist, and it does work, and I imagine it's pretty solid.
Toss in a few OS optimizations for this case (that currently don't buy much as most unix style processes end up doing "exec" and loading in new code) and it would be better yet.
Really? Plenty of Unix-style processes, especially servers, do exactly what you're suggesting -- fork a process, but no exec.
The threshold of caring is subjective. If you are launching a new process to respond to a mouse move message you probably still care that process launch is expensive.
It's also technically solveable -- I'm guessing a lot of the reason Unix servers do this so often is because Unix (Linux in particular) is very fast and efficient at forking.
So, given that example: If that's an Erlang process for a mouse move message, I don't care anymore.
If you bought a released product, then the standard policy applies, period.
I assume, then, that if you preordered (and thus have beta access), then once you upgrade to the released product, the standard policy starts to apply?
All around, I'm actually glad that this policy exists. It's simple, and explicit, and it sets an example.
And I don't think that the "common denominator" argument holds -- in many ways, people find OS X and even Ubuntu to be more intuitive than Windows -- even when you consider that too often, "intuitive" means "just like Windows, because I already know that." But OS X and Ubuntu both come more secure out of the box than really any Windows desktop OS other than Vista. (I haven't used enough Vista to be sure, and I don't want to.)
I think that the only part of this that causes problems is when Microsoft needs to make Windows behave exactly the way it always has.
A simple example: No, we don't need Autorun to stay exactly the same. Almost every piece of software comes with a manual that includes how to run setup.exe if it doesn't start automatically. Even ignoring that, it would be possible to pop up a list of options when the new disc is detected, based on what's detected, including "run the program on it" -- or simply to open the disc in a new window, thus making it exactly one click (a double-click, if you must) to start the installer, if that's what you intended.
And no, that's not going to cover everything -- but it could at least cover the things that education realistically can't. (Even experienced users can't realistically be expected to hold shift every time they insert a CD.)
I admit CSS is pretty good across WebKit, Gecko, and even IE7. (IE6 is a mess). But functionality -- DHTML type stuff, manipulating the DOM or CSS from Javascript, is still pretty different across all of them.
I'm talking about both, and again, very little difference. There are, as always, some browser-specific things, but if you follow the spec, you're mostly alright.
But maybe I've been spoiled by jQuery, lately.
As a user and as a developer, I don't see how more than one or two rendering engines benefits us.
First, I need to apologize -- this is ridiculously long. I'm going to try to bold-ify the important points, so you can skim through it.
I believe I've explained above, but it was buried in that rant about Flash. So let me be clear:
As a user, multiple engines benefit me directly, because if there's a problem with one, I can use another. They also benefit me because one size cannot fit all -- I don't often have problems with my Linux GUI, but when I do, I can use lynx from a virtual terminal. I doubt Webkit could be made to run there.
As a developer, multiple engines benefit me less directly, because while I don't often run into a bug in one particular engine, I can always test it on the others. If my page works in Webkit, Gecko, Trident (IE), and Presto (Opera), I can be reasonably sure it follows at least some subset of the spec.
If it breaks in Trident, I can still be pretty confident, because IE has such a shitty record.
But if it runs in Gecko, and breaks in Webkit -- or if it runs in Safari, but breaks in Konqueror -- I have to figure out whether my code is wrong (and Gecko was just more tolerant), or whether Webkit or Konqueror is wrong (and I should submit a bug to them), or whether the spec is too vague (and I should submit a suggestion to the spec people).
This is a pain for me as a developer, right now. It's a pain for users if I miss a browser.
But in the long run, it means that all three (my site, the browser, and the spec) get more robust. My code won't end up depending on some bug, or some transitory (but undefined) behavior, and break with an upgrade. All the rendering engines will get some bug fixes, and get closer to the spec. And the spec itself will be made more precise and explicit.
And that's indirectly good for users, too -- since they get some of the benefits of the One True Engine (all sites behave about the same), and the sites themselves have the opportunity to be more robust.
I've already shown Flash -- let me give you another example of where it went even more horribly wrong.
You see, Windows has a published API. Microsoft doesn't follow it precisely in any version of Windows, which means that developers have to work around (and come to depend on) broken behavior. And Microsoft really can't fix this -- every time they fix some part of the API to actually follow their own spec, thus closing an actual bug, making implementation simpler, and making it easy for developers...
Every time they do that, they break some third-party app which depends on the broken behavior.
In fact, they don't even have to change the API to do that. Some programs break simply because the Windows version number is too high -- classic newbie mistakes like
if (major_version < 3 || minor_version < 1) { // Alert the user that we need at least Windows 3.1, and exit. }
Of course, that example has the problem of not working with a version that reports itself as 4.0, because the minor version is less than one, even though the version as a whole is greater than 3.1.
That's not all -- too many really old programs allocate a fixed-length string in which to put things like a version number. Then, when the version is longer than they expected (say, Windows 3.11), BAM, buffer overflow and the program crashes.
The developers of adblock and adblock plus haven't been sued, after all.
True, but they're not also selling advertising.
It would be a bit like Slysoft selling a DRM solution, and including the crack in AnyDVD. I don't know if it's actually illegal, but I doubt anyone would want to do business with them.
And with threaded tabs, it kicks Firefox's ass up and down the street.
Firefox, maybe... Safari, maybe...
Interesting fact: Konqueror seems to be using a separate process for each window. Not necessarily for each tab, but absolutely for each window.
Worth mentioning: They aren't threads (in Chrome), they're processes. And they aren't foolproof -- on release, it was trivially possible to crash the entire Chrome browser. Say what you will, but Firefox and Safari are reasonably robust -- I've no doubt that Chrome will surpass them, but it hasn't happened yet.
I'm a web developer, and here's what I've observed -- not all firsthand, but research it yourself if you like:
For years, it was IE vs Netscape, each adding features ad-hoc, without too much concern for standards. This sucked. You'd have to do everything twice -- once for IE, and once for Netscape.
So yes, a lot of us just said "fuck it" and went with IE, which was (at the time) smaller, lighter, and faster than Netscape, and already installed on most people's computers. And that was a step forward.
I, personally, was in that group when I first learned HTML.
Then, I discovered Linux. And I discovered that pretty much the only game in town for Linux (at least on GNOME) was Mozilla. And I discovered that in many ways, Mozilla was better than IE. But many, many websites were fairly broken with Mozilla, since Mozilla tended to follow the standards, whereas IE tended to break them horribly. The "fuck it" developers weren't checking for standards, they were just firing up IE to see if it ran.
So this is when I started being in favor of web standards -- though at the time, I pretty much assumed that Mozilla was the defacto implementation of the "real" standards, and so where Mozilla and IE disagreed, I assumed Mozilla was correct.
So when I would develop my own personal website, I'd make them work on Mozilla -- or Phoenix (I was in there since around 0.6), or Firefox. Then, if I detected that the browser wasn't doing something right, I'd slap a banner across the top explaining that I didn't have time to debug Microsoft bullshit, so the page might not work as expected, and here's a link to Firefox.
Don't bother, by the way -- my own website hasn't existed in any usable form for years. No time... I should stop posting to Slashdot.
For sites I was paid to develop, I'd make it work in the Mozilla browser du jour first, then I'd figure out how to hack it to work with IE, if that was a requirement. This added significantly to development time, but I was on Linux, so I wasn't about to fire up IE under Wine just to view my finished product -- it had to work in both.
I've gradually become aware of other browsers, like Konqueror, Safari, and Opera, but I've also discovered that my procedure hasn't changed. Maybe once every three or four months, I have to deal with a glitch in Firefox, or in Safari -- mostly, I just don't touch anything but Firefox for development (because of Firebug). But weekly, I have to deal with IE -- the only reason it's not daily is that I wait for other people to test it in IE, and that happens once a week.
Try it sometime, though -- develop entirely for any decent browser except IE. Then try it on as many browsers as you like. I bet at least one thing will break on IE, and I bet it'll work exactly the same everywhere else.
Everyone should just adopt it.
This is dangerous thinking. I used to think this way about other things -- let Linux be the standard; let everyone just adopt it. And if I'd had my way, we wouldn't have ZFS, among other things.
You'll never get everyone to just adopt one implementation. Even if you start out that way, if it's open, people will fork it. If it's closed, and you actually do get some adoption, well, you become Microsoft Office, or Flash, or any of the other examples I could point to of something without real competition, but with horrible implementation deficiencies that make it completely unusable at times.
The best you can do is provide one standard, and one reference implementation. But even in this case, it's entirely possible that a second implementation would flush out some bugs in that reference implementation, or even some vagueness in the standard that should be rectified.
I would say that it's more important for a standard to have a working reference implementation than a flawless spec. And I'd say it's more important for a standard to have a test suite for that reference implementation -- both unit tests, and higher-level, portable tests like Acid -- than to have an English spec.
Now there's the link tag but it's optional.. yeah, that's right, the standard says that a browser can optionally implement the tag.. what kind of standard is that anyway?
One that makes sense?
Out of curiosity -- when was the last time you used lynx? Or links2? Or w3m? Browsers don't even have to implement images at all.
Seems to me, about the best they can do is define what the behavior should be when implemented. So, I'd suggest just using the link tag -- it's not like your page will break if it's not implemented, it'll just be slightly slower.
And I've found that prefetching images isn't useful, most of the time. Let the browser cache do its job.
Thankfully the interest in Acid tests has taken on this role. Unfortunately even a lot of stuff that is in the acid test never makes it back to the standard, so browser developers have to reverse engineer the Acid test!
Aren't the Acid tests documented?
Sure, it's easier if you only have to read the standards, but if you're just looking for a higher Acid test score, that seems like the obvious solution.
Flash is an example of something that seemingly progressed well, perhaps faster than browsers, while having essentially no competition.
It's not quite what it seems to be...
You make some interesting points, and your point about Flash isn't entirely invalid, but Flash is also a great example of the sheer lunacy of pinning any kind of "web standard" on a single closed implementation from a single vendor.
Let's start with the basics: Flash is slow. Version 10 might finally get hardware acceleration -- OpenGL has been available for how long, again?
Firefox already uses Cairo, a cross-platform vector graphics engine, which already has some acceleration, and is having more added to it -- but, being its own library, Cairo should be able to benefit other projects than Firefox. Flash hardware acceleration only benefits Adobe products.
Flash video is an absolute nightmare. It's probably the worst possible way to give me a movie to watch. All the controls must be done in Flash, or in the surrounding HTML -- which is great for particularly control-freak designers, but sucks if I want to, say, attach my own controls? (Think Apple Remote on a Mac, or just a global hotkey on Linux.) It's slow -- absurdly so, on the order of ten to a hundred times slower than any other video player I could find.
Yes, that slow. I compared with mplayer and VLC on Linux with Adobe's Flash player. I used the Video Downloader extension to grab the FLV. Turns out, mplayer and VLC use maybe 2%, if I go fullscreen. Flash uses 50%, even in a tiny YouTube window, and is unwatchably laggy fullscreen.
And, you see, if you give me any other format -- Windows Media, Quicktime, mpeg, Theora, Dirac, whatever -- it'll load up whatever player I decide to plugin to my browser. If one sucks, I can use another.
But see, Flash has no competition, and gives me no source code, which means that when things don't work well, I'm SOL.
I believe Gnash is finally good enough to watch YouTube, or getting close -- but keep in mind how many years Flash was out, and how much catching-up Gnash has to do. And Adobe's not helping -- the spec is still proprietary; you can get it under a license which basically lets you do anything you want with it, except develop a player. (WTF? Why anything but a player? Don't they make their money from the server products and creators anyway?)
Now, it's true, Flash was able to include shiny new features faster than browser. But when browsers do include those features, they get done right. Look at the HTML5 video tag -- not quite as many features as Flash, but out of the box, it'll talk to Javascript (so you can write those controls in AJAX), it's trivially easy to add to a page, somewhat more lightweight, and it's entirely up to each browser how they want to implement it -- nothing stopping you from giving the user some playback controls of their own.
Safari already has it -- ties into native QuickTime, I'd guess, which means it should be fast for h.264 and such.
Of course I've been saying for a while that MS should pick up either Gecko or WebKit and not create another rendering platform.
If MS could get it right, I'd say they should go ahead and keep using their own, or develop a new one. The more the merrier.
Where we see problems are when MS gets it horribly wrong, and the entire fucking industry has to pay for their mistakes.
I'd love to see an outside team fully develop a QT/Webkit/Xulrunner fork of Firefox that allows me to use Firefox extensions on top of a Webkit rendering engine.
I'd love that, too, but I'm not sure how it would work. How much hacking would it take for Qt/Webkit to support XUL?
Because it's impossible to design something which looks really good without having control.
Citation needed. I'm not a designer, but I do strongly disagree.
For that matter, there's a bit of a false dichotomy here, on both sides -- you all seem to be assuming that setting things to the pixel is the only way to get control, and giving up that per-pixel control is the only way to get resolution independence.
I would consider PDF to be resolution-independent, yet every document always looks exactly the same, everywhere, even on every third-party reader I've ever tried.
That said, I do think it's possible to design something that looks good without adjusting things to the pixel. I lost this argument at work, and we're using fixed-with, fixed-pixel everything -- even using images on our HTML buttons, because most people use an ugly widget set, so we have to control that thoroughly.
But there are definitely cases where giving up a bit of control (insisting on a particular button style, for example) is a gain in flexibility (now partially-blind people can use a high-contrast color scheme, and it'll work on our buttons).
Slashdot Mirror
I understand that this is the case now. I am pointing out why it failed in the first place -- note that I've used past tense in pretty much my entire post.
The Mac/PC ads are tired, lame,
Maybe so -- but they certainly were not "tired" when they came out, at least. The Seinfeld ad was just pointless when it came out -- OK, I chuckled, but I still want those 30 seconds of my life back.
and full of lies ("Only Macs are able to work with Japanese digital cameras!!"
I don't believe that was the point -- more that they do so out of the box, easily, with no issues. At the time, the same couldn't be said for PCs -- at the very least, you'd have to install the software that came with the camera. Since Microsoft has no control over that software, it's entirely hit or miss whether it's any good.
Since they never explicitly stated anything like that, I can only assume that the other "lies" and "bullshit" is your own misinterpretation, and not anything actually in the ad.
Disclaimer: I don't use either, entirely. I run Linux on PC hardware, and occasionally boot XP for games.
Yes it is a commercial but how many commercials do you actually laugh at?
The Mac/PC ones, I actually laughed at -- and it also contained some reference to the actual product being pitched!
Why would a file start to download simply due to a user highlighting it (aka Select)?
Not quite. Workflow is:
- User hits "browse"
- User selects file (or more than one)
- User clicks "Select", or "OK", or whatever the "confirm this dialog" button is
- We start uploading the file.
So, if by "confirmation button" you mean some arbitrary Submit button, you're right, we don't wait for that. But it's not as though we can immediately grab the file just because you're looking at it in your browse window. You can always cancel that window, and we'll never know what you clicked.
The point is, these are large-ish files, and a lot of them (5-10) -- so especially over slower links, we want to make it as quick as possible to select which ones, and we want the upload to start as early as possible -- not before.
THanks for giving another reason why Flash is a buggy, insecure POS.
No more so, in this case, than the browser itself. Consider: Any data you type into an input field, whether you submit or not, could easily be intercepted by a script and sent back via AJAX. Before XHR, it could have been done with a hidden iframe.
The browser has quite a lot more potential control over uploads -- Konqueror prompts me directly immediately before any file is sent. But what is stopping a page from intercepting a file upload field's onChange event, and submitting the form? (I haven't checked -- maybe this has been addressed.)
But this isn't a point against Flash, it's a point against Flash being closed-source. See, most users would much rather have the behavior we've got now. If you'd rather have the uploads be more explicit, an open source flash would let you write that capability.
and the method used before by the extensions isn't supported anymore.
So, was there once an extension for multi-file upload?
But in Linux - in most advanced desktop distro Ubuntu - the easiest method ... right - e-mail.
Mostly because you already know how. Arguably, there are many alternatives, some quite easy.
Setting up (not installed by default) FTPd/OpenSSH/Avahi - is not something I can advise to end users to install setup by default.
FTP would be a poor choice, anyway, for many reasons.
writing off everything on "security via obscurity". As if sending confidential data over 3rd party is safer than sending them over LAN...
Well, if you're on a wireless network, and the 3rd party at least uses SSL, then yes, it is more secure.
And yes, it should be easy -- however, kludging together something like FTP/Avahi isn't really a great idea.
Avahi, by the way, comes installed out of the box, doesn't it? And setting up openssh is pretty much just "sudo apt-get install openssh-server", and you're done -- the hardest part would be finding the current IP.
One of the big reasons no one had any interest in minix is the incredible performance hit the design entails.
At what point?
I think the main reason no one had an interest in Minix was the cost, and the restrictive licensing. Linus admitted that he never expected Linux to be much more than a stopgap until GNU/HURD was released -- except that HURD took too long to get any kind of release out the door, so Linux already had adoption at that point.
The best argument at the time was: You could spend the money and buy Minix, and install it. And then install the source code, and download a number of patches needed to get something approximating a modern OS, recompile, and reinstall.
Or you could spend that same money on a faster computer (a 386), and get Linux for free. Linux could do everything Minix could, and it already ran in native 32-bit mode (which Minix needed patches for).
In fact, that's one of several other ways Minix took performance hits -- ways that I'd call bad design. The filesystem, for example -- Minix has a non-threaded filesystem; Linux had a threaded filesystem.
Unfortunately, there are a great many things Flash does for which there are no alternatives, open or otherwise.
Let me give you a recent, stupid example: We want to let users upload a bunch of things at once. We have three options:
1: Build something using multiple file upload fields. (This could be done elegantly -- by hiding one as soon as it's set, and generating a new one.) In other words, we force the user to select each file individually, and click browse again -- and the files can't start uploading until they've all been selected.
2: Accept zipfiles. Extra work for us (admittedly not much), and extra work for them.
3: Use Flash. Not only can they select more than one file in the open dialog (ctrl+click, shift+click, ctrl+a, etc), but as soon as they select one, we can start uploading it.
I want to use open alternatives. I hate Flash more than... I'm not a very hateful person, but Flash makes me homicidal. But even something as simple as that, there's an advantage to using Flash.
Also Kopete is cross-platform these days with binaries on Solaris, BSD, Mac, Windows and Linux.
So what's the problem with using Kopete in GNOME again?
"Kopete is for KDE" is like saying "Firefox is for GNOME". To be fair, Firefox isn't as tied to GNOME, and could be ported to Qt, whereas Kopete almost certainly links in KDElibs -- but that's no reason you can't use it, unless you're severely low on RAM.
I'm confused -- why is this on Idle? Shouldn't it be YRO, or politics, or something?
Safari, I don't know, I won't pay extra to make my computer a style accessory.
I assume you're talking about buying a Mac.
Given that you're running Chrome, I assume you're on Windows. Safari does have a Windows port.
Sure, it's not the best Windows port. And sure, if you were going to criticize it, the default response would be "It's better on a Mac." But it does exist, and it does work, and I imagine it's pretty solid.
What part of that counters my suggestion?
Fine, we can be technical -- I'd feel better if they put their source code in escrow. Or a compiled version that's not encumbered.
It is slow
Are you sure that's not Flash? Or nspluginwrapper?
and little javascript / css menu dropdowns appear behind flash objects
Known bug. I think Flash finally solves it, but only in recent versions of Flash and Firefox 3, and only on 32-bit.
Maybe it is adobe's fault...
<rant>Everything is Adobe's fault.</rant>
Toss in a few OS optimizations for this case (that currently don't buy much as most unix style processes end up doing "exec" and loading in new code) and it would be better yet.
Really? Plenty of Unix-style processes, especially servers, do exactly what you're suggesting -- fork a process, but no exec.
The threshold of caring is subjective. If you are launching a new process to respond to a mouse move message you probably still care that process launch is expensive.
It's also technically solveable -- I'm guessing a lot of the reason Unix servers do this so often is because Unix (Linux in particular) is very fast and efficient at forking.
So, given that example: If that's an Erlang process for a mouse move message, I don't care anymore.
If you bought a released product, then the standard policy applies, period.
I assume, then, that if you preordered (and thus have beta access), then once you upgrade to the released product, the standard policy starts to apply?
All around, I'm actually glad that this policy exists. It's simple, and explicit, and it sets an example.
Good and useful information -- thanks!
And I don't think that the "common denominator" argument holds -- in many ways, people find OS X and even Ubuntu to be more intuitive than Windows -- even when you consider that too often, "intuitive" means "just like Windows, because I already know that." But OS X and Ubuntu both come more secure out of the box than really any Windows desktop OS other than Vista. (I haven't used enough Vista to be sure, and I don't want to.)
I think that the only part of this that causes problems is when Microsoft needs to make Windows behave exactly the way it always has.
A simple example: No, we don't need Autorun to stay exactly the same. Almost every piece of software comes with a manual that includes how to run setup.exe if it doesn't start automatically. Even ignoring that, it would be possible to pop up a list of options when the new disc is detected, based on what's detected, including "run the program on it" -- or simply to open the disc in a new window, thus making it exactly one click (a double-click, if you must) to start the installer, if that's what you intended.
And no, that's not going to cover everything -- but it could at least cover the things that education realistically can't. (Even experienced users can't realistically be expected to hold shift every time they insert a CD.)
I admit CSS is pretty good across WebKit, Gecko, and even IE7. (IE6 is a mess). But functionality -- DHTML type stuff, manipulating the DOM or CSS from Javascript, is still pretty different across all of them.
I'm talking about both, and again, very little difference. There are, as always, some browser-specific things, but if you follow the spec, you're mostly alright.
But maybe I've been spoiled by jQuery, lately.
As a user and as a developer, I don't see how more than one or two rendering engines benefits us.
First, I need to apologize -- this is ridiculously long. I'm going to try to bold-ify the important points, so you can skim through it.
I believe I've explained above, but it was buried in that rant about Flash. So let me be clear:
As a user, multiple engines benefit me directly, because if there's a problem with one, I can use another. They also benefit me because one size cannot fit all -- I don't often have problems with my Linux GUI, but when I do, I can use lynx from a virtual terminal. I doubt Webkit could be made to run there.
As a developer, multiple engines benefit me less directly, because while I don't often run into a bug in one particular engine, I can always test it on the others. If my page works in Webkit, Gecko, Trident (IE), and Presto (Opera), I can be reasonably sure it follows at least some subset of the spec.
If it breaks in Trident, I can still be pretty confident, because IE has such a shitty record.
But if it runs in Gecko, and breaks in Webkit -- or if it runs in Safari, but breaks in Konqueror -- I have to figure out whether my code is wrong (and Gecko was just more tolerant), or whether Webkit or Konqueror is wrong (and I should submit a bug to them), or whether the spec is too vague (and I should submit a suggestion to the spec people).
This is a pain for me as a developer, right now. It's a pain for users if I miss a browser.
But in the long run, it means that all three (my site, the browser, and the spec) get more robust. My code won't end up depending on some bug, or some transitory (but undefined) behavior, and break with an upgrade. All the rendering engines will get some bug fixes, and get closer to the spec. And the spec itself will be made more precise and explicit.
And that's indirectly good for users, too -- since they get some of the benefits of the One True Engine (all sites behave about the same), and the sites themselves have the opportunity to be more robust.
I've already shown Flash -- let me give you another example of where it went even more horribly wrong.
You see, Windows has a published API. Microsoft doesn't follow it precisely in any version of Windows, which means that developers have to work around (and come to depend on) broken behavior. And Microsoft really can't fix this -- every time they fix some part of the API to actually follow their own spec, thus closing an actual bug, making implementation simpler, and making it easy for developers...
Every time they do that, they break some third-party app which depends on the broken behavior.
In fact, they don't even have to change the API to do that. Some programs break simply because the Windows version number is too high -- classic newbie mistakes like
Of course, that example has the problem of not working with a version that reports itself as 4.0, because the minor version is less than one, even though the version as a whole is greater than 3.1.
That's not all -- too many really old programs allocate a fixed-length string in which to put things like a version number. Then, when the version is longer than they expected (say, Windows 3.11), BAM, buffer overflow and the program crashes.
The only reason Microsoft
But not through "a pinch of DNS poisoning or muxed up routes".
The developers of adblock and adblock plus haven't been sued, after all.
True, but they're not also selling advertising.
It would be a bit like Slysoft selling a DRM solution, and including the crack in AnyDVD. I don't know if it's actually illegal, but I doubt anyone would want to do business with them.
And with threaded tabs, it kicks Firefox's ass up and down the street.
Firefox, maybe... Safari, maybe...
Interesting fact: Konqueror seems to be using a separate process for each window. Not necessarily for each tab, but absolutely for each window.
Worth mentioning: They aren't threads (in Chrome), they're processes. And they aren't foolproof -- on release, it was trivially possible to crash the entire Chrome browser. Say what you will, but Firefox and Safari are reasonably robust -- I've no doubt that Chrome will surpass them, but it hasn't happened yet.
I'm a web developer, and here's what I've observed -- not all firsthand, but research it yourself if you like:
For years, it was IE vs Netscape, each adding features ad-hoc, without too much concern for standards. This sucked. You'd have to do everything twice -- once for IE, and once for Netscape.
So yes, a lot of us just said "fuck it" and went with IE, which was (at the time) smaller, lighter, and faster than Netscape, and already installed on most people's computers. And that was a step forward.
I, personally, was in that group when I first learned HTML.
Then, I discovered Linux. And I discovered that pretty much the only game in town for Linux (at least on GNOME) was Mozilla. And I discovered that in many ways, Mozilla was better than IE. But many, many websites were fairly broken with Mozilla, since Mozilla tended to follow the standards, whereas IE tended to break them horribly. The "fuck it" developers weren't checking for standards, they were just firing up IE to see if it ran.
So this is when I started being in favor of web standards -- though at the time, I pretty much assumed that Mozilla was the defacto implementation of the "real" standards, and so where Mozilla and IE disagreed, I assumed Mozilla was correct.
So when I would develop my own personal website, I'd make them work on Mozilla -- or Phoenix (I was in there since around 0.6), or Firefox. Then, if I detected that the browser wasn't doing something right, I'd slap a banner across the top explaining that I didn't have time to debug Microsoft bullshit, so the page might not work as expected, and here's a link to Firefox.
Don't bother, by the way -- my own website hasn't existed in any usable form for years. No time... I should stop posting to Slashdot.
For sites I was paid to develop, I'd make it work in the Mozilla browser du jour first, then I'd figure out how to hack it to work with IE, if that was a requirement. This added significantly to development time, but I was on Linux, so I wasn't about to fire up IE under Wine just to view my finished product -- it had to work in both.
I've gradually become aware of other browsers, like Konqueror, Safari, and Opera, but I've also discovered that my procedure hasn't changed. Maybe once every three or four months, I have to deal with a glitch in Firefox, or in Safari -- mostly, I just don't touch anything but Firefox for development (because of Firebug). But weekly, I have to deal with IE -- the only reason it's not daily is that I wait for other people to test it in IE, and that happens once a week.
Try it sometime, though -- develop entirely for any decent browser except IE. Then try it on as many browsers as you like. I bet at least one thing will break on IE, and I bet it'll work exactly the same everywhere else.
Everyone should just adopt it.
This is dangerous thinking. I used to think this way about other things -- let Linux be the standard; let everyone just adopt it. And if I'd had my way, we wouldn't have ZFS, among other things.
You'll never get everyone to just adopt one implementation. Even if you start out that way, if it's open, people will fork it. If it's closed, and you actually do get some adoption, well, you become Microsoft Office, or Flash, or any of the other examples I could point to of something without real competition, but with horrible implementation deficiencies that make it completely unusable at times.
The best you can do is provide one standard, and one reference implementation. But even in this case, it's entirely possible that a second implementation would flush out some bugs in that reference implementation, or even some vagueness in the standard that should be rectified.
I would say that it's more important for a standard to have a working reference implementation than a flawless spec. And I'd say it's more important for a standard to have a test suite for that reference implementation -- both unit tests, and higher-level, portable tests like Acid -- than to have an English spec.
Now there's the link tag but it's optional.. yeah, that's right, the standard says that a browser can optionally implement the tag.. what kind of standard is that anyway?
One that makes sense?
Out of curiosity -- when was the last time you used lynx? Or links2? Or w3m? Browsers don't even have to implement images at all.
Seems to me, about the best they can do is define what the behavior should be when implemented. So, I'd suggest just using the link tag -- it's not like your page will break if it's not implemented, it'll just be slightly slower.
And I've found that prefetching images isn't useful, most of the time. Let the browser cache do its job.
Thankfully the interest in Acid tests has taken on this role. Unfortunately even a lot of stuff that is in the acid test never makes it back to the standard, so browser developers have to reverse engineer the Acid test!
Aren't the Acid tests documented?
Sure, it's easier if you only have to read the standards, but if you're just looking for a higher Acid test score, that seems like the obvious solution.
Flash is an example of something that seemingly progressed well, perhaps faster than browsers, while having essentially no competition.
It's not quite what it seems to be...
You make some interesting points, and your point about Flash isn't entirely invalid, but Flash is also a great example of the sheer lunacy of pinning any kind of "web standard" on a single closed implementation from a single vendor.
Let's start with the basics: Flash is slow. Version 10 might finally get hardware acceleration -- OpenGL has been available for how long, again?
Firefox already uses Cairo, a cross-platform vector graphics engine, which already has some acceleration, and is having more added to it -- but, being its own library, Cairo should be able to benefit other projects than Firefox. Flash hardware acceleration only benefits Adobe products.
Flash video is an absolute nightmare. It's probably the worst possible way to give me a movie to watch. All the controls must be done in Flash, or in the surrounding HTML -- which is great for particularly control-freak designers, but sucks if I want to, say, attach my own controls? (Think Apple Remote on a Mac, or just a global hotkey on Linux.) It's slow -- absurdly so, on the order of ten to a hundred times slower than any other video player I could find.
Yes, that slow. I compared with mplayer and VLC on Linux with Adobe's Flash player. I used the Video Downloader extension to grab the FLV. Turns out, mplayer and VLC use maybe 2%, if I go fullscreen. Flash uses 50%, even in a tiny YouTube window, and is unwatchably laggy fullscreen.
And, you see, if you give me any other format -- Windows Media, Quicktime, mpeg, Theora, Dirac, whatever -- it'll load up whatever player I decide to plugin to my browser. If one sucks, I can use another.
But see, Flash has no competition, and gives me no source code, which means that when things don't work well, I'm SOL.
I believe Gnash is finally good enough to watch YouTube, or getting close -- but keep in mind how many years Flash was out, and how much catching-up Gnash has to do. And Adobe's not helping -- the spec is still proprietary; you can get it under a license which basically lets you do anything you want with it, except develop a player. (WTF? Why anything but a player? Don't they make their money from the server products and creators anyway?)
Now, it's true, Flash was able to include shiny new features faster than browser. But when browsers do include those features, they get done right. Look at the HTML5 video tag -- not quite as many features as Flash, but out of the box, it'll talk to Javascript (so you can write those controls in AJAX), it's trivially easy to add to a page, somewhat more lightweight, and it's entirely up to each browser how they want to implement it -- nothing stopping you from giving the user some playback controls of their own.
Safari already has it -- ties into native QuickTime, I'd guess, which means it should be fast for h.264 and such.
Of course I've been saying for a while that MS should pick up either Gecko or WebKit and not create another rendering platform.
If MS could get it right, I'd say they should go ahead and keep using their own, or develop a new one. The more the merrier.
Where we see problems are when MS gets it horribly wrong, and the entire fucking industry has to pay for their mistakes.
I'd love to see an outside team fully develop a QT/Webkit/Xulrunner fork of Firefox that allows me to use Firefox extensions on top of a Webkit rendering engine.
I'd love that, too, but I'm not sure how it would work. How much hacking would it take for Qt/Webkit to support XUL?
Because it's impossible to design something which looks really good without having control.
Citation needed. I'm not a designer, but I do strongly disagree.
For that matter, there's a bit of a false dichotomy here, on both sides -- you all seem to be assuming that setting things to the pixel is the only way to get control, and giving up that per-pixel control is the only way to get resolution independence.
I would consider PDF to be resolution-independent, yet every document always looks exactly the same, everywhere, even on every third-party reader I've ever tried.
That said, I do think it's possible to design something that looks good without adjusting things to the pixel. I lost this argument at work, and we're using fixed-with, fixed-pixel everything -- even using images on our HTML buttons, because most people use an ugly widget set, so we have to control that thoroughly.
But there are definitely cases where giving up a bit of control (insisting on a particular button style, for example) is a gain in flexibility (now partially-blind people can use a high-contrast color scheme, and it'll work on our buttons).