The browsers' 3D support is not part of any open standards process afaik... they each have their own, albeit similar, custom extensions to CSS transforms
I was thinking of WebGL, which is a standard, though not necessarily a W3C standard. It's an extension of canvas, not CSS.
Yeah, but you need to run the wiki software on your machine
Not really...
or download a static set of pages that will have a lot of non-working links that you have to clean up
after all, you can't "edit" the page,
So what? You're talking about developer documentation, and I'm sure a developer could figure that out.
and the random page link has to be replaced with some big horking javascript that has a list of all pages),
Was that ever useful? Especially in API docs.
Seems to me that those two changes could be trivially scripted, if someone wanted to make this possible. Also seems like the framesets won't automagically work, unless, of course, you wget -r, or someone provides you the static sources.
I'm not sure when exactly the tag was included, but that's when "hot linking" became a problem.
For which there was a trivial solution in the form of referer -- but I also remember hotlinking not being a problem for a long time, though it was certainly possible.
"Hot linking" and "click-jacking" are two sides of the same coin; They're only possible because there's no standard in place to tell the browser, "Don't display this content if the page's host address doesn't match the resource's address."
And in 20/20 hindsight, that makes sense and even seems obvious. But when looking at the img tag problem, I wouldn't immediately think, "Maybe one day people will be able to display HTML from another site in something, I think I'll call it a 'frame', and that won't be able to use the referer header, and it could be really bad."
Referrer validation is just as broken as TFA's frame busting JavaScript code since browsers can be configured to disable both JavaScript and the HTTP referrer.
...WTF?
Browsers can also be configured (or written) to disable anything you might suggest.
It seems silly to me "hot linking" and "click-jacking" can both be prevented via a simple extension to HTTP and HTML,
And it's hard to add any "simple" extension to HTTP or HTML -- just look at the ongoing HTML5 debate. Now, it is happening in a sideways, unofficial way (to HTTP), and it may make its way into the standard, but it's still going to be awhile before we can assume users have updated their browsers to support it, assuming all browsers implement it.
I still have the disks so I'm sure they didn't come for free.
RedHat once made a commercial desktop OS, but it was also available for download for free. Yellow Dog may have been the same, and I know there are several services which sell Linux CDs for those who can't (or don't want to) burn them themselves.
Apple seems to have good support, they are even based here in the U.S. and seems to be at Apple's HQ. I've used them on a number of occasions to track down hardware glitches.
I've had support refused on my laptop because it had a dent in it, from a year before the incident, and they wanted $1700 to replace the backlight in a used Powerbook, mainly because they wanted to replace the entire screen (and, because the screen is the most expensive item, everything else) rather than the backlight.
Meanwhile, Dell will insure my laptop against any damage, and Sharp replaced my hard drive at least once without complaining, maybe twice, can't recall.
I also discovered a bug in OS X related to keyboard configuration -- it forgot my keyboard settings on every reboot, probably because I had an unusual setting (I used command+semicolon for something, and I use Dvorak). I reported it to Apple, and as far as I know, they never fixed it, as long as I was using that Powerbook.
Had the same problem occurred on Linux, worst case, I'd have written a simple boot script to fix it. I've since been told that the same is possible on OS X, but I never found out how.
I don't mind paying extra for the box + OS and bundled software.
That, I get, so long as you acknowledge how much more you're paying. But you don't, you keep lying to yourself:
Those packages are not that different than comparable systems from other manufacturers.Those packages are not that different than comparable systems from other manufacturers.
Do you really need as much computer -- hardware or software -- as Apple is giving you?
At one point, I thought as you did, and I would price out similar Macbooks and Dells to show people. They came back with a slightly less powerful machine for half the price, and there was no comparable Mac. It works at the other end of the scale, too -- as you start pricing more and more powerful Macs (especially Mac Pros), the Apple markup gets worse and worse, until you're talking about anywhere from two to ten thousand dollars cheaper for a comparable PC.
(Yet I've seen university departments buy Macs to use as headless, ssh-only Unix machines. WTF?)
Now, you might decide that a Mac is worth twice the price of an almost-comparable PC. You might also decide that it's a small consideration compared to the price of various pieces of software you need. Whatever. But the fact that you keep repeating this lie of "comparable systems" tells me that you don't want to think you're spending twice as much.
I think you think buying a computer means buying the hardware.
No, there's also support. Dell will come to my house to fix my hardware issues, and I can fix my own software issues, few as they are. And I bought this laptop because it came with Linux, which meant that while I paid a little more and got a little less, I also got a guarantee that all my hardware would work on Linux without hacks.
By contrast, you were closer when you said I look at whether it will run Linux -- the Mac is going to cost more and give me OS X, which I like less. It'd have to be a lot better to justify that cost.
Does Apple support third party RAM...errr...this is a trick question, right? There's a whole industry built around supporting Apple products and that industry is not owned by Apple.
Nope, not a trick question, though maybe a dumb one. If I install RAM from that industry, will Apple still support my machine? Or, what's Apple's policy on third-party RAM?
The W3C's dodgy corporatism has really got to you;-).
Or possibly a complete lack of impressive demos, while there's now an entire 3D world in Flash, and, as you point out, some ports of 3D games in JavaScript.
I hope that;-) means you realize that neither Java nor Flash are less corporate than the W3C -- if anything, just the opposite.
The GPU can do more processing, so there's no need to create an ultra-efficient binary for acceptable 3D performance where the CPU may take up the slack.
That's been the case basically since we've had GPUs. If the CPU takes up the slack, I would think it'd do so within the graphics APIs, thus it'd be within "an ultra-efficient binary" and not in JavaScript itself.
That's not true at all -- Flash video competed with and beat players such as QuickTime, RealPlayer, and Windows Media Player.
If you mean in the marketplace, again, look up "market failure". Flash is not now and never has been just a video player -- it got installed everywhere for people to look at stupid Flash games. Video was added as an afterthought, but since it was there and "just worked", it beat the other players you mentioned, which might force people to install something else.
No, it beat Java, because that was its only actual competition at the time. Then it used marketshare to beat QuickTime and Windows Media Player. (It may legitimately be better than RealPlayer -- I'll give you that.)
If you'll set your Libertarian "The Market Is Always Right" goggles for a moment and look at actual benchmarks, you might find that Flash performs terribly compared to things like modern QuickTime, let alone VLC. That means battery drain at least, and often a slideshow at higher resolutions.
I actually like the design of HTML, and the direction it's going. From what little I've seen of Flash development, I can't say the same.
Then you really have seen very little of Flash development.
What, I'd automatically like the direction if I saw more? That's pretty arrogant of you. Of course, your double negative makes it even more hilarious.
As someone who has developed serious apps in both, the difference is night and day -- consistent, well-documented APIs (vs. a fragmented and buggy mess in browsers),
So you're saying you developed in raw HTML and JavaScript, without using any of the frameworks that have built up around it?
far better backwards compatibility across runtime versions,
I call bullshit on that, and there are many pages on archive.org that might demonstrate it also -- HTML tends to be very backwards-compatible, assuming you developed it to the standard in the first place.
stronger development tools and debuggers,
When was the last time you did this? I see all kinds of development tools and debuggers, a few decent ones built into my browser (Chrome).
ridiculously better networking APIs,
For 99% of my purposes, vanilla HTTP (REST) is fine. XMLHttpRequest sucks, but it's also trivially wrapped.
An additional.9% of the time, WebSockets should do well.
That leaves 0.1% of the time for which, I'll admit, Flash has much stronger networking capabilities.
a superior programming language,
Strongly disagree. JavaScript is a great programming language, and one of the reasons it's so good is prototypal inheritance. If you'd like to point out something ActionScript does better, I'll gladly point to a library I could write in ten minutes to do the same in JavaScript.
one of the best UI frameworks (Flex) I have ever worked with,
If you say so. As a user, flash UIs pretty much universally suck, especially compared to similar HTML UIs. (As a developer, I haven't worked with Flex.)
with a much more sensible layout model.
Erm... CSS3? Or would you like to point out some specifics?
We are welcome to look at the source for Firefox and for WebKit, find out that they've implemented things differently,... and be none the wiser.
And how would it be different if there was an official w3c browser? Amaya is an examlpe of how a single standard implementation doesn't necessarily solve the issue. How well does Flash conform to its own specs?
This being said, if you ever have to consult the code then there is a problem with the specification and an erratum needs to be issued.
Indeed, but there are always problems with the specification. Another problem I suggested is a hypothetical spec which no one is sure can be implemented at all, let alone well. This is why you need at least a proof-of-concept.
What exactly does this mean? HTML may be encumbered by patents on certain proecesses, but W3C contributors have agreed on royalty-free licensing; anyone else might point out a feature in HTML they think is covered by one of their patents (e.g. BT).
HTML has also existed for over a decade without (as far as I know) any patents being filed against it.
Similarly, Adobe has agreed to royalty-free licensing on anything they may have a patent for in the Flash spec.
To the extent that they've released it. There's still the DRM'd bits.
Also, to the extent that they can. They can't exactly grant an h.264 license to everyone. Or is that not part of the spec?
DRM's inherent broken-ness means its implementation cannot be released.
Indeed, but it's also something that does not belong in a public web standard at all, or in a compliant plugin.
Maybe if Flash dies providers will move to forcing you to download a DRM binary native plug-in, or at least try and fail to issue obfuscated Javascript...
I suspect the latter, which I'd be fine with -- they would fail, and it would at least be as portable as JavaScript is. I can't see them going with the former, though -- if people aren't enabling Flash, why would they enable another binary plugin? At worst, I could see them jumping ship to Silverlight, which seems like a profoundly stupid idea.
don't imagine for a moment that content providers will "oh well, never mind!" and remove DRM
Depends who it is. I don't know that YouTube ever had DRM enabled in Flash, but they certainly haven't tried with HTML5.
There is one fairly good working implementation which works on the majority of desktops, and one slower implementation (Mac) which works on most of the rest.
Yeah, not good enough. Again, Mac and Linux are very good at playing video. Flash on Mac and Linux sucks at playing video. Flash even sucks at playing video on Windows, it's just not quite as bad.
It is hard to monetise the development of an alternative Flash player, whereas it is easy to do so with web browsers via sponsored searches...
You don't think people could find a way to do so?
Of course, there are multiple open source web browsers, so I don't buy that either.
Many alternative Flash authoring tools exist and are used, so the spec is clearly readable.
Or maybe it's easier to generate content than to consume it? Just a thought. "Be conservative in what you produce, liberal in what you accept."
As a trivial example, compare building an HTML page, or even an HTML template engine, to building a web browser. I don't have to have even read the spec once to build the page, and I can run it through validation to make sure it's compliant.
It's just not nearly as "collaborative" right now as the W3C's adherents would have you believe.
Doesn't have to be, so long as it's not controlled by a single company, particularly one which has historically not played nice with others.
they are making flash for non-x86 due out first on android devices this year.
They've had it on PPC for awhile (but OS X only), and I wouldn't be surprised to see other builds on ARM. The point is that it's not something I can install on any old Linux distro -- in this case, maybe I can install it on a custom Android setup, maybe not, but Android doesn't run X, IIRC.
Of course, were it open source, it'd be ported to everyone and their dog's favorite platform ages ago. That's the point here.
they also desperately wanted to get it on the iphone
And if so, it'd be like the PPC version -- iPhone OS only. Certainly wouldn't imply that any old Linux user would be able to download an ARM version of Flash the way I can download an x86 version.
they also have power-pc flash been around for a good wile but they have abandon it due to the death of power-pc.
Erm, why do they have to abandon it? And what's this "death"? Sure, Apple isn't using PPC anymore, but it's still in all modern game consoles, for instance. So we again have no Linux player on any of these devices.
and arm being widly used is a recent thing
The Linux kernel was ported to over a dozen architectures, last I checked. Why does a platform have to be "widely used" for you to compile for it? And why does Flash have to be proprietary, so we can't do this ourselves?
As "recently" as five years ago, I was running Linux on an old-at-the-time handheld PC with an ARM processor. Couldn't run Flash on that, either.
before how many people relly had a arm based pc it wasn't very many.
Tons, actually, they just weren't PCs.
I'm also not sure what any of this has to do with anything I said.
So what you are saying is that the current Adobe way of doing it is correct: implement, specify, analyse, enhance, repeat.
Nope, I actually clarified that:
presuming there's at least one open source implementation.
There isn't a complete open source implementation of Flash. There aren't multiple implementations of a Flash player, closed or not, which implement anywhere close to the full spec. On top of all of this, Flash is patent-encumbered -- HTML itself is not.
And yes, source matters. That way, if there's any ambiguity in the spec, or question about how to implement something, I can look at what appears to be a compliant implementation and see how it's done. With Flash, I'd have to reverse engineer Adobe's player -- something explicitly forbidden by their license.
And the problem... is that Adobe makes a good enough closed source implementation which no-one has bothered to compete with?
Gnash exists, which proves people are trying.
The problem is that as others have pointed out, Adobe doesn't seem to release everything (DRM in particular), nor do they release the specs at all quickly, nor have they released an open source player of their own.
It really does seem like this is the reason Gnash and others haven't caught up, as your claim is absurd on its face -- mplayer can play fullscreen 1080p video smoothly on this system, using software decoding. Flash not only becomes a slideshow when trying, but also becomes completely unresponsive, to the point where it won't even let me exit fullscreen mode. This has been the case for as long as I've tried YouTube's fullscreen option.
Flash has never been a good player, they've just always been the only player.
So we should all stick to HTML/JavaScript/CSS, the user agents for which are full of non-standard extensions...
...which you use at your own peril, because, as I pointed out, there are other browsers.
In the case of Flash, there's less standardized than there is implemented in the exactly one, defacto standard player. In that sense, the best possible spin you could put on this is that Gnash is a bit like the pre-Firefox Mozilla -- slightly better in a few ways almost no one will notice, worse in many others, including compatibility with all the content which was written with only one implementation (IE) in mind.
Of course, we could also consider the fact that the Flash specs and Flash player are produced by exactly one company, while HTML is a collaborative process.
The only thing going for the W3C is that certain members are large enough that they can buy out some proprietary codec and dump it on the market to push out the competition.
That, and I can actually get a fully functional, fully open source implementation of that codec, and the other standards surrounding it. Oh, and there are multiple test suites available for how correct and performant a given browser is. And as a user, I can hack apart sites with user scripts and make them do what I want, not what the author wants.
Quality matters. I actually like the design of HTML, and the direction it's going. From what little I've seen of Flash development, I can't say the same.
If you really want to prove how much Flash has going for it, prove us all wrong and build a competing player.
It's possible I'm thinking of a different vulnerability, but some quick reading elsewhere reveals that the only way framebusting scripts can currently work is to be at the top of the page, and to keep the page hidden until they've made sure they're not framed. It's tricky to support JavaScript if you're going to do that.
Why don't browser vendors just update (i)frames to same-origin rather than cross-origin?
Because it'd break HTML-only widgets. Example: embedded YouTube videos. Right now, you embed a Flash file, but in the future, they could conceivably use iFrames.
There are legitimate uses for (i)frames, but ever since the overly-annoying XHRs (XMLHTTPREQUEST) came around...
Nope, XHR can't provide the above without introducing cross-site scripting vulnerabilities, or requiring you to trust every single widget producer. I think Facebook allows third-party apps to plug in in a similar fashion, and I doubt you could get Facebook itself to trust Farmville etc.
XHRs are plain fucking awful to work with, to put it nicely.
So is raw HTTP, if you do it right. That's why sane people use abstraction layers.
XHR is still a HACK.
What about them, specifically, do you find hackish? The only thing I dislike about XHR is the fact that it still forces HTTP, that we can't do real socket programming with web browsers yet.
Then we look at frames, it is as simple as setting targets and making anchors. It creates logical separation in a webpage. It is easy to setup. It is syntactically meaningful.
It is also navigationally a clusterfuck, if you use them as HTML. How do I bookmark where I currently am in the app? By the time you wire in enough JavaScript for me to be able to grab the hashcode, you may as well have used XHR in the first place.
But if you try to use it as an actual replacement for XHR -- for example, by writing a full-blown, rich-client web application, something like, oh, Google Docs -- what happens to navigation? With XHR, it's very clear -- this is something only exposed to the script, it's only meaningful to the back and forward buttons if the script says so. With iframes, how does the browser know whether it's script-only (thus not part of navigation) or something exposed directly as a frame to the user? It can't, so it just ties them to navigation. Now, how do I disable navigation if I'm only using it in my script, say, to ping an RSS feed?
It sounds to me like iframes are much more of a hack than XHR ever was.
Let's not forget, the guys "in control", the W3C felt the need to KILL the element in favor of a hack-up of unrelated elements (A LIST IS NOT A MENU!)
What? Why not?
Screw syntactically meaningful HTML, huzzah for anonymous...
What? Of course you can do syntactically meaningful HTML. You can even build a REST interface on top of that, and then consume that interface with XHR, or anything else you want.
At least HTML5 started getting back on the right track,
Not really. People keep pointing out canvas as a step in precisely the wrong direction, despite its obvious usefulness.
On a slightly related note, the same applies for GOTO, you don't scream at your computer for GOTOing every nanosecond, do you? Yet people bitch and moan at the slightest mention of GOTO because "IT IS EVIL, IT IS THE COMMAND OF SATAN!"
Wow, you're just ranting about everything today.
No, I don't bitch when my computer JMPs every nanosecond. I also don't bitch when my VM does dozens of mallocs and frees per second. But we've developed higher-level constructs for a reason, and you'd better have a damned good reason for going lower level.
In particular, GOTO is considered harmful not because it magically makes your code go poof, but because it can lead to spaghetti code, and will at least be far less readable the vast majority of the time. If you have a case where GOTO makes sense, you'd better have a damned good explanation, just as you'd better have a damned good explanation for why you rewrote something in assembly, or why you insist on using C in apps for which security i
First, I agree that framesets themselves could go away and be replaced by scrollable divs. But clickjacking doesn't work on traditional framesets anyway, and as someone pointed out, various API docs put them to good use.
Second, there's a few tricks which conceivably could be better supported in other ways, but not all have working replacements. For example, before XMLHttpRequest, a hidden iFrame was the way to make asynchronous background requests from JavaScript -- and if you care about old browsers, you could actually write an AJAX framework that gracefully degrades to this. Another example is file uploads -- currently, the best way to upload files is probably (unfortunately) Flash, with its ability to upload multiple files from a single browse dialog. The second-best way is what GMail currently does -- you click an iFrame'd "browse" button, select your file, and after some delay (in case you grabbed the wrong file), it'll auto-submit that iframe, in the background. Smarter uploaders even give you a progress bar, allowing you to upload multiple files at once and watch their progress, all without leaving the page.
But most importantly... I said something good about Flash, so here's the obligatory rant: Flash is currently used for, among other things, "widgets". A year or two ago, I was working on a music widget site. The widget itself started out being pure HTML, using Flash only to play the audio, and I was planning to replace the Flash with an HTML5 audio tag. By the time I left, we had a pure-Flash version of the widget, so that anyone, on any page, even restrictive MySpace pages, could simply embed it -- apparently, Flash makes it easy to embed untrusted widgets (like the YouTube player, for instance) into your site.
The only reasonable alternative to that, if you want actual, interactive widgets, is an iframe. Yes, you could just grab the HTML and inject it into your own page, but then you open yourself up massively (Goatse-style) to cross-site scripting attacks. The only safe way to do that would be to scrub the HTML -- but that would (obviously) mean removing anything resembling a script, and thus, again, you can't have interactive widgets.
Indeed, one of the proposed solutions strikes me as particularly useless -- allow a custom header to deny loading a given page in a frame. Seems like it would be much saner to simply block the technique in question -- it relies on being able to re-style an iframe, scroll it, move it around, etc. In particular, I think only registering clicks on either fully visible iframes or same-domain iframes would solve this, unless I'm missing something?
Oh yes... Netbooks. With such a bloated Vista, and with the price of Windows often being as much as the entire price of a netbook, it seemed like Windows was completely unsuitable -- only Linux could survive in such an environment.
Then Microsoft made the tiniest of changes -- they extended support for XP, and offered it cheaply enough to be compelling. It's still a horrible choice, but people use it anyway, because it lets them run Windows apps.
Now people are saying Windows is the wrong OS for tablets. I predict more of the same -- yes, Windows is the wrong OS for tablets, but that won't prevent it from being fantastically successful.
Not so very long ago we were limited to animated GIFs or Flash.
Five years ago or more, I would guess.
I still really like the vector drawing tools in Flash,
Can't argue with that, other than, have you tried Inkscape?
This information is not stored on some inaccessible obsolete disks that can't be read any more, its out there on the internet, and only becoming inaccessible because of companies being dicks.
Companies like Adobe, or Macromedia before them, which you had to trust when you created Flash content. So again, let me say this clearly: It was your fault, and the fault of anyone producing content in these formats. We saw this coming, and warned you, and this is far from the worst you were warned could happen.
Are we supposed to just forget about all that information and pretend it never happened?
Not necessarily, but if we are to preserve it, we're going to have to find an alternative. What you described with Gnash seems the best possible solution, and it still sucks, partly because of patents.
I also worked as a web developer before I went back to school. I did mention "web apps I've developed for work and play."
Even so, in what way is homework "not reality"? My programs either work or they don't, and they'll be graded by people likely running a different OS and CPU architecture from me.
Oh? What's not open about what the W3C is building?
the major corporate sponsors of W3C create proprietary extensions such as canvas
Erm, so what? It's also now supported on all major browsers.
So the implementation comes before the standard.
As it should be, presuming there's at least one open source implementation. While this can be dangerous -- HTML5's SQL Storage spec often refers to "What SQLite does", and that would be much more cause for serious concern if it weren't for the fact that SQLite is public domain and used by all implementors -- it can be equally dangerous to create a standardized spec before any working implementations exist to demonstrate that it's possible, practical, or efficient to implement.
Many standards work exactly this way. ODF was adapted from OpenOffice's native format, which was originally used only by StarOffice, which was originally proprietary. Theora was originally proprietary, as was VP8.
So what's your point? Does the fact that something was once proprietary and vendor-specific preclude it being a true open standard? It certainly highlights the difference between that and something like Flash, in which the version everyone uses is the version for which the specs haven't yet been released, and for which much of the implementation is covered by patents.
If only there was some sort of market system in which people could compete to offer different codecs.
Slashdot Mirror
there is also open source flash out there look up the flex sdk.
Yeah, it's not a player. Doesn't count.
as well as a few open source players. but not as good as there closed version.
Unless something has changed recently, "not as good" translates to "nearly unusable".
The browsers' 3D support is not part of any open standards process afaik... they each have their own, albeit similar, custom extensions to CSS transforms
I was thinking of WebGL, which is a standard, though not necessarily a W3C standard. It's an extension of canvas, not CSS.
Yeah, but you need to run the wiki software on your machine
Not really...
or download a static set of pages that will have a lot of non-working links that you have to clean up
after all, you can't "edit" the page,
So what? You're talking about developer documentation, and I'm sure a developer could figure that out.
and the random page link has to be replaced with some big horking javascript that has a list of all pages),
Was that ever useful? Especially in API docs.
Seems to me that those two changes could be trivially scripted, if someone wanted to make this possible. Also seems like the framesets won't automagically work, unless, of course, you wget -r, or someone provides you the static sources.
I'm not sure when exactly the tag was included, but that's when "hot linking" became a problem.
For which there was a trivial solution in the form of referer -- but I also remember hotlinking not being a problem for a long time, though it was certainly possible.
"Hot linking" and "click-jacking" are two sides of the same coin; They're only possible because there's no standard in place to tell the browser, "Don't display this content if the page's host address doesn't match the resource's address."
And in 20/20 hindsight, that makes sense and even seems obvious. But when looking at the img tag problem, I wouldn't immediately think, "Maybe one day people will be able to display HTML from another site in something, I think I'll call it a 'frame', and that won't be able to use the referer header, and it could be really bad."
Referrer validation is just as broken as TFA's frame busting JavaScript code since browsers can be configured to disable both JavaScript and the HTTP referrer.
...WTF?
Browsers can also be configured (or written) to disable anything you might suggest.
It seems silly to me "hot linking" and "click-jacking" can both be prevented via a simple extension to HTTP and HTML,
And it's hard to add any "simple" extension to HTTP or HTML -- just look at the ongoing HTML5 debate. Now, it is happening in a sideways, unofficial way (to HTTP), and it may make its way into the standard, but it's still going to be awhile before we can assume users have updated their browsers to support it, assuming all browsers implement it.
I still have the disks so I'm sure they didn't come for free.
RedHat once made a commercial desktop OS, but it was also available for download for free. Yellow Dog may have been the same, and I know there are several services which sell Linux CDs for those who can't (or don't want to) burn them themselves.
Apple seems to have good support, they are even based here in the U.S. and seems to be at Apple's HQ. I've used them on a number of occasions to track down hardware glitches.
I've had support refused on my laptop because it had a dent in it, from a year before the incident, and they wanted $1700 to replace the backlight in a used Powerbook, mainly because they wanted to replace the entire screen (and, because the screen is the most expensive item, everything else) rather than the backlight.
Meanwhile, Dell will insure my laptop against any damage, and Sharp replaced my hard drive at least once without complaining, maybe twice, can't recall.
I also discovered a bug in OS X related to keyboard configuration -- it forgot my keyboard settings on every reboot, probably because I had an unusual setting (I used command+semicolon for something, and I use Dvorak). I reported it to Apple, and as far as I know, they never fixed it, as long as I was using that Powerbook.
Had the same problem occurred on Linux, worst case, I'd have written a simple boot script to fix it. I've since been told that the same is possible on OS X, but I never found out how.
I don't mind paying extra for the box + OS and bundled software.
That, I get, so long as you acknowledge how much more you're paying. But you don't, you keep lying to yourself:
Those packages are not that different than comparable systems from other manufacturers.Those packages are not that different than comparable systems from other manufacturers.
Do you really need as much computer -- hardware or software -- as Apple is giving you?
At one point, I thought as you did, and I would price out similar Macbooks and Dells to show people. They came back with a slightly less powerful machine for half the price, and there was no comparable Mac. It works at the other end of the scale, too -- as you start pricing more and more powerful Macs (especially Mac Pros), the Apple markup gets worse and worse, until you're talking about anywhere from two to ten thousand dollars cheaper for a comparable PC.
(Yet I've seen university departments buy Macs to use as headless, ssh-only Unix machines. WTF?)
Now, you might decide that a Mac is worth twice the price of an almost-comparable PC. You might also decide that it's a small consideration compared to the price of various pieces of software you need. Whatever. But the fact that you keep repeating this lie of "comparable systems" tells me that you don't want to think you're spending twice as much.
I think you think buying a computer means buying the hardware.
No, there's also support. Dell will come to my house to fix my hardware issues, and I can fix my own software issues, few as they are. And I bought this laptop because it came with Linux, which meant that while I paid a little more and got a little less, I also got a guarantee that all my hardware would work on Linux without hacks.
By contrast, you were closer when you said I look at whether it will run Linux -- the Mac is going to cost more and give me OS X, which I like less. It'd have to be a lot better to justify that cost.
Does Apple support third party RAM...errr...this is a trick question, right? There's a whole industry built around supporting Apple products and that industry is not owned by Apple.
Nope, not a trick question, though maybe a dumb one. If I install RAM from that industry, will Apple still support my machine? Or, what's Apple's policy on third-party RAM?
The W3C's dodgy corporatism has really got to you ;-).
Or possibly a complete lack of impressive demos, while there's now an entire 3D world in Flash, and, as you point out, some ports of 3D games in JavaScript.
I hope that ;-) means you realize that neither Java nor Flash are less corporate than the W3C -- if anything, just the opposite.
The GPU can do more processing, so there's no need to create an ultra-efficient binary for acceptable 3D performance where the CPU may take up the slack.
That's been the case basically since we've had GPUs. If the CPU takes up the slack, I would think it'd do so within the graphics APIs, thus it'd be within "an ultra-efficient binary" and not in JavaScript itself.
That's not true at all -- Flash video competed with and beat players such as QuickTime, RealPlayer, and Windows Media Player.
If you mean in the marketplace, again, look up "market failure". Flash is not now and never has been just a video player -- it got installed everywhere for people to look at stupid Flash games. Video was added as an afterthought, but since it was there and "just worked", it beat the other players you mentioned, which might force people to install something else.
No, it beat Java, because that was its only actual competition at the time. Then it used marketshare to beat QuickTime and Windows Media Player. (It may legitimately be better than RealPlayer -- I'll give you that.)
If you'll set your Libertarian "The Market Is Always Right" goggles for a moment and look at actual benchmarks, you might find that Flash performs terribly compared to things like modern QuickTime, let alone VLC. That means battery drain at least, and often a slideshow at higher resolutions.
I actually like the design of HTML, and the direction it's going. From what little I've seen of Flash development, I can't say the same.
Then you really have seen very little of Flash development.
What, I'd automatically like the direction if I saw more? That's pretty arrogant of you. Of course, your double negative makes it even more hilarious.
As someone who has developed serious apps in both, the difference is night and day -- consistent, well-documented APIs (vs. a fragmented and buggy mess in browsers),
So you're saying you developed in raw HTML and JavaScript, without using any of the frameworks that have built up around it?
far better backwards compatibility across runtime versions,
I call bullshit on that, and there are many pages on archive.org that might demonstrate it also -- HTML tends to be very backwards-compatible, assuming you developed it to the standard in the first place.
stronger development tools and debuggers,
When was the last time you did this? I see all kinds of development tools and debuggers, a few decent ones built into my browser (Chrome).
ridiculously better networking APIs,
For 99% of my purposes, vanilla HTTP (REST) is fine. XMLHttpRequest sucks, but it's also trivially wrapped.
An additional .9% of the time, WebSockets should do well.
That leaves 0.1% of the time for which, I'll admit, Flash has much stronger networking capabilities.
a superior programming language,
Strongly disagree. JavaScript is a great programming language, and one of the reasons it's so good is prototypal inheritance. If you'd like to point out something ActionScript does better, I'll gladly point to a library I could write in ten minutes to do the same in JavaScript.
one of the best UI frameworks (Flex) I have ever worked with,
If you say so. As a user, flash UIs pretty much universally suck, especially compared to similar HTML UIs. (As a developer, I haven't worked with Flex.)
with a much more sensible layout model.
Erm... CSS3? Or would you like to point out some specifics?
We are welcome to look at the source for Firefox and for WebKit, find out that they've implemented things differently,... and be none the wiser.
And how would it be different if there was an official w3c browser? Amaya is an examlpe of how a single standard implementation doesn't necessarily solve the issue. How well does Flash conform to its own specs?
This being said, if you ever have to consult the code then there is a problem with the specification and an erratum needs to be issued.
Indeed, but there are always problems with the specification. Another problem I suggested is a hypothetical spec which no one is sure can be implemented at all, let alone well. This is why you need at least a proof-of-concept.
What exactly does this mean? HTML may be encumbered by patents on certain proecesses, but W3C contributors have agreed on royalty-free licensing; anyone else might point out a feature in HTML they think is covered by one of their patents (e.g. BT).
HTML has also existed for over a decade without (as far as I know) any patents being filed against it.
Similarly, Adobe has agreed to royalty-free licensing on anything they may have a patent for in the Flash spec.
To the extent that they've released it. There's still the DRM'd bits.
Also, to the extent that they can. They can't exactly grant an h.264 license to everyone. Or is that not part of the spec?
DRM's inherent broken-ness means its implementation cannot be released.
Indeed, but it's also something that does not belong in a public web standard at all, or in a compliant plugin.
Maybe if Flash dies providers will move to forcing you to download a DRM binary native plug-in, or at least try and fail to issue obfuscated Javascript...
I suspect the latter, which I'd be fine with -- they would fail, and it would at least be as portable as JavaScript is. I can't see them going with the former, though -- if people aren't enabling Flash, why would they enable another binary plugin? At worst, I could see them jumping ship to Silverlight, which seems like a profoundly stupid idea.
don't imagine for a moment that content providers will "oh well, never mind!" and remove DRM
Depends who it is. I don't know that YouTube ever had DRM enabled in Flash, but they certainly haven't tried with HTML5.
There is one fairly good working implementation which works on the majority of desktops, and one slower implementation (Mac) which works on most of the rest.
Yeah, not good enough. Again, Mac and Linux are very good at playing video. Flash on Mac and Linux sucks at playing video. Flash even sucks at playing video on Windows, it's just not quite as bad.
It is hard to monetise the development of an alternative Flash player, whereas it is easy to do so with web browsers via sponsored searches...
You don't think people could find a way to do so?
Of course, there are multiple open source web browsers, so I don't buy that either.
Many alternative Flash authoring tools exist and are used, so the spec is clearly readable.
Or maybe it's easier to generate content than to consume it? Just a thought. "Be conservative in what you produce, liberal in what you accept."
As a trivial example, compare building an HTML page, or even an HTML template engine, to building a web browser. I don't have to have even read the spec once to build the page, and I can run it through validation to make sure it's compliant.
It's just not nearly as "collaborative" right now as the W3C's adherents would have you believe.
Doesn't have to be, so long as it's not controlled by a single company, particularly one which has historically not played nice with others.
they are making flash for non-x86 due out first on android devices this year.
They've had it on PPC for awhile (but OS X only), and I wouldn't be surprised to see other builds on ARM. The point is that it's not something I can install on any old Linux distro -- in this case, maybe I can install it on a custom Android setup, maybe not, but Android doesn't run X, IIRC.
Of course, were it open source, it'd be ported to everyone and their dog's favorite platform ages ago. That's the point here.
they also desperately wanted to get it on the iphone
And if so, it'd be like the PPC version -- iPhone OS only. Certainly wouldn't imply that any old Linux user would be able to download an ARM version of Flash the way I can download an x86 version.
they also have power-pc flash been around for a good wile but they have abandon it due to the death of power-pc.
Erm, why do they have to abandon it? And what's this "death"? Sure, Apple isn't using PPC anymore, but it's still in all modern game consoles, for instance. So we again have no Linux player on any of these devices.
and arm being widly used is a recent thing
The Linux kernel was ported to over a dozen architectures, last I checked. Why does a platform have to be "widely used" for you to compile for it? And why does Flash have to be proprietary, so we can't do this ourselves?
As "recently" as five years ago, I was running Linux on an old-at-the-time handheld PC with an ARM processor. Couldn't run Flash on that, either.
before how many people relly had a arm based pc it wasn't very many.
Tons, actually, they just weren't PCs.
I'm also not sure what any of this has to do with anything I said.
Java has had 3D for a very long time. Close to a decade, actually.
Was it actually hardware-accelerated? People keep pointing this out...
Now that we have way more GPU power, 3D can be inefficiently shunted into browsers
Sorry, what?
You could make a case if it was CPU power -- and thanks to Chrome, you'd lose -- but how, exactly, does JavaScript put more strain on the GPU?
So what you are saying is that the current Adobe way of doing it is correct: implement, specify, analyse, enhance, repeat.
Nope, I actually clarified that:
presuming there's at least one open source implementation.
There isn't a complete open source implementation of Flash. There aren't multiple implementations of a Flash player, closed or not, which implement anywhere close to the full spec. On top of all of this, Flash is patent-encumbered -- HTML itself is not.
And yes, source matters. That way, if there's any ambiguity in the spec, or question about how to implement something, I can look at what appears to be a compliant implementation and see how it's done. With Flash, I'd have to reverse engineer Adobe's player -- something explicitly forbidden by their license.
And the problem... is that Adobe makes a good enough closed source implementation which no-one has bothered to compete with?
Gnash exists, which proves people are trying.
The problem is that as others have pointed out, Adobe doesn't seem to release everything (DRM in particular), nor do they release the specs at all quickly, nor have they released an open source player of their own.
It really does seem like this is the reason Gnash and others haven't caught up, as your claim is absurd on its face -- mplayer can play fullscreen 1080p video smoothly on this system, using software decoding. Flash not only becomes a slideshow when trying, but also becomes completely unresponsive, to the point where it won't even let me exit fullscreen mode. This has been the case for as long as I've tried YouTube's fullscreen option.
Flash has never been a good player, they've just always been the only player.
So we should all stick to HTML/JavaScript/CSS, the user agents for which are full of non-standard extensions...
...which you use at your own peril, because, as I pointed out, there are other browsers.
...and don't fully implement previous years' standards either?
In the case of Flash, there's less standardized than there is implemented in the exactly one, defacto standard player. In that sense, the best possible spin you could put on this is that Gnash is a bit like the pre-Firefox Mozilla -- slightly better in a few ways almost no one will notice, worse in many others, including compatibility with all the content which was written with only one implementation (IE) in mind.
Of course, we could also consider the fact that the Flash specs and Flash player are produced by exactly one company, while HTML is a collaborative process.
The only thing going for the W3C is that certain members are large enough that they can buy out some proprietary codec and dump it on the market to push out the competition.
That, and I can actually get a fully functional, fully open source implementation of that codec, and the other standards surrounding it. Oh, and there are multiple test suites available for how correct and performant a given browser is. And as a user, I can hack apart sites with user scripts and make them do what I want, not what the author wants.
Quality matters. I actually like the design of HTML, and the direction it's going. From what little I've seen of Flash development, I can't say the same.
If you really want to prove how much Flash has going for it, prove us all wrong and build a competing player.
Its always seemed silly to me that this wasn't in the standards to begin with...
To begin with? Are you serious?
I mean, "clickjacking" is something which was invented, long after iframes were invented, and iframes weren't in the standard to begin with.
Not all browsers support this, and those that do only do so very recently.
erm, whoops, this is what preview is for...
I meant, it's tricky to support noscript if you're going to do that. Possible (I think?), but tricky.
It's possible I'm thinking of a different vulnerability, but some quick reading elsewhere reveals that the only way framebusting scripts can currently work is to be at the top of the page, and to keep the page hidden until they've made sure they're not framed. It's tricky to support JavaScript if you're going to do that.
Why don't browser vendors just update (i)frames to same-origin rather than cross-origin?
Because it'd break HTML-only widgets. Example: embedded YouTube videos. Right now, you embed a Flash file, but in the future, they could conceivably use iFrames.
There are legitimate uses for (i)frames, but ever since the overly-annoying XHRs (XMLHTTPREQUEST) came around...
Nope, XHR can't provide the above without introducing cross-site scripting vulnerabilities, or requiring you to trust every single widget producer. I think Facebook allows third-party apps to plug in in a similar fashion, and I doubt you could get Facebook itself to trust Farmville etc.
XHRs are plain fucking awful to work with, to put it nicely.
So is raw HTTP, if you do it right. That's why sane people use abstraction layers.
XHR is still a HACK.
What about them, specifically, do you find hackish? The only thing I dislike about XHR is the fact that it still forces HTTP, that we can't do real socket programming with web browsers yet.
Then we look at frames, it is as simple as setting targets and making anchors. It creates logical separation in a webpage. It is easy to setup. It is syntactically meaningful.
It is also navigationally a clusterfuck, if you use them as HTML. How do I bookmark where I currently am in the app? By the time you wire in enough JavaScript for me to be able to grab the hashcode, you may as well have used XHR in the first place.
But if you try to use it as an actual replacement for XHR -- for example, by writing a full-blown, rich-client web application, something like, oh, Google Docs -- what happens to navigation? With XHR, it's very clear -- this is something only exposed to the script, it's only meaningful to the back and forward buttons if the script says so. With iframes, how does the browser know whether it's script-only (thus not part of navigation) or something exposed directly as a frame to the user? It can't, so it just ties them to navigation. Now, how do I disable navigation if I'm only using it in my script, say, to ping an RSS feed?
It sounds to me like iframes are much more of a hack than XHR ever was.
Let's not forget, the guys "in control", the W3C felt the need to KILL the element in favor of a hack-up of unrelated elements (A LIST IS NOT A MENU!)
What? Why not?
Screw syntactically meaningful HTML, huzzah for anonymous...
What? Of course you can do syntactically meaningful HTML. You can even build a REST interface on top of that, and then consume that interface with XHR, or anything else you want.
At least HTML5 started getting back on the right track,
Not really. People keep pointing out canvas as a step in precisely the wrong direction, despite its obvious usefulness.
On a slightly related note, the same applies for GOTO, you don't scream at your computer for GOTOing every nanosecond, do you?
Yet people bitch and moan at the slightest mention of GOTO because "IT IS EVIL, IT IS THE COMMAND OF SATAN!"
Wow, you're just ranting about everything today.
No, I don't bitch when my computer JMPs every nanosecond. I also don't bitch when my VM does dozens of mallocs and frees per second. But we've developed higher-level constructs for a reason, and you'd better have a damned good reason for going lower level.
In particular, GOTO is considered harmful not because it magically makes your code go poof, but because it can lead to spaghetti code, and will at least be far less readable the vast majority of the time. If you have a case where GOTO makes sense, you'd better have a damned good explanation, just as you'd better have a damned good explanation for why you rewrote something in assembly, or why you insist on using C in apps for which security i
So, people have mentioned a few things.
First, I agree that framesets themselves could go away and be replaced by scrollable divs. But clickjacking doesn't work on traditional framesets anyway, and as someone pointed out, various API docs put them to good use.
Second, there's a few tricks which conceivably could be better supported in other ways, but not all have working replacements. For example, before XMLHttpRequest, a hidden iFrame was the way to make asynchronous background requests from JavaScript -- and if you care about old browsers, you could actually write an AJAX framework that gracefully degrades to this. Another example is file uploads -- currently, the best way to upload files is probably (unfortunately) Flash, with its ability to upload multiple files from a single browse dialog. The second-best way is what GMail currently does -- you click an iFrame'd "browse" button, select your file, and after some delay (in case you grabbed the wrong file), it'll auto-submit that iframe, in the background. Smarter uploaders even give you a progress bar, allowing you to upload multiple files at once and watch their progress, all without leaving the page.
But most importantly... I said something good about Flash, so here's the obligatory rant: Flash is currently used for, among other things, "widgets". A year or two ago, I was working on a music widget site. The widget itself started out being pure HTML, using Flash only to play the audio, and I was planning to replace the Flash with an HTML5 audio tag. By the time I left, we had a pure-Flash version of the widget, so that anyone, on any page, even restrictive MySpace pages, could simply embed it -- apparently, Flash makes it easy to embed untrusted widgets (like the YouTube player, for instance) into your site.
The only reasonable alternative to that, if you want actual, interactive widgets, is an iframe. Yes, you could just grab the HTML and inject it into your own page, but then you open yourself up massively (Goatse-style) to cross-site scripting attacks. The only safe way to do that would be to scrub the HTML -- but that would (obviously) mean removing anything resembling a script, and thus, again, you can't have interactive widgets.
Indeed, one of the proposed solutions strikes me as particularly useless -- allow a custom header to deny loading a given page in a frame. Seems like it would be much saner to simply block the technique in question -- it relies on being able to re-style an iframe, scroll it, move it around, etc. In particular, I think only registering clicks on either fully visible iframes or same-domain iframes would solve this, unless I'm missing something?
What, and wikis can't be downloaded?
Oh yes... Netbooks. With such a bloated Vista, and with the price of Windows often being as much as the entire price of a netbook, it seemed like Windows was completely unsuitable -- only Linux could survive in such an environment.
Then Microsoft made the tiniest of changes -- they extended support for XP, and offered it cheaply enough to be compelling. It's still a horrible choice, but people use it anyway, because it lets them run Windows apps.
Now people are saying Windows is the wrong OS for tablets. I predict more of the same -- yes, Windows is the wrong OS for tablets, but that won't prevent it from being fantastically successful.
Not so very long ago we were limited to animated GIFs or Flash.
Five years ago or more, I would guess.
I still really like the vector drawing tools in Flash,
Can't argue with that, other than, have you tried Inkscape?
This information is not stored on some inaccessible obsolete disks that can't be read any more, its out there on the internet, and only becoming inaccessible because of companies being dicks.
Companies like Adobe, or Macromedia before them, which you had to trust when you created Flash content. So again, let me say this clearly: It was your fault, and the fault of anyone producing content in these formats. We saw this coming, and warned you, and this is far from the worst you were warned could happen.
Are we supposed to just forget about all that information and pretend it never happened?
Not necessarily, but if we are to preserve it, we're going to have to find an alternative. What you described with Gnash seems the best possible solution, and it still sucks, partly because of patents.
I see no mention of "player" which suggests I'm allowed to write a third-party player. The specs have been available for at least that long...
All it mentions is "removing restrictions", which is pretty vague.
Homework is not "reality."
I also worked as a web developer before I went back to school. I did mention "web apps I've developed for work and play."
Even so, in what way is homework "not reality"? My programs either work or they don't, and they'll be graded by people likely running a different OS and CPU architecture from me.
That would require moving myself and all my users out of USA, Germany, and South Korea.
That, or civil disobedience.
Which format? MPEG-LA claims that WebM infringes.
They have yet to show that it does. That's a bit like Microsoft claiming they have dozens of patents Linux infringes on.
There's also Dirac and Theora.
Unfortunately, it doesn't look good for video codecs right now. Flash solves exactly none of that.
No, that is what it claims to be...
Oh? What's not open about what the W3C is building?
the major corporate sponsors of W3C create proprietary extensions such as canvas
Erm, so what? It's also now supported on all major browsers.
So the implementation comes before the standard.
As it should be, presuming there's at least one open source implementation. While this can be dangerous -- HTML5's SQL Storage spec often refers to "What SQLite does", and that would be much more cause for serious concern if it weren't for the fact that SQLite is public domain and used by all implementors -- it can be equally dangerous to create a standardized spec before any working implementations exist to demonstrate that it's possible, practical, or efficient to implement.
Many standards work exactly this way. ODF was adapted from OpenOffice's native format, which was originally used only by StarOffice, which was originally proprietary. Theora was originally proprietary, as was VP8.
So what's your point? Does the fact that something was once proprietary and vendor-specific preclude it being a true open standard? It certainly highlights the difference between that and something like Flash, in which the version everyone uses is the version for which the specs haven't yet been released, and for which much of the implementation is covered by patents.
If only there was some sort of market system in which people could compete to offer different codecs.
Google "Market failure".
Is that available in the browser, though?