> Expressing your opinion is one thing (name calling shouting, debating, etc.).
That depends. Under current law in many cases shouting at someone is in fact treated as a hate crime. Depends on who's doing the shouting and who's being shouted at. Not sure that's a good thing, mind you, but it's what the law says.
> ANYONE who violently oppress' someone else for their beliefs should be prosecuted as a > "Hate Crime" regardless of who is doing the oppressing.
Fully agreed, except I'm not sure we need the "Hate Crime" bit. Just prosecute them for the actual illegal actions they took.
> The gay community isn't exactly going out of its way to violently oppress those who oppose > it, while the other side can't say the same.
That depends on where you live and how you define "gay community". In California during the Proposition 8 debates and right after its passage there was quite a number of rather ugly incidents.
http://www.christianexaminer.com/Articles/Articles%20Dec08/Art_Dec08_09.html lists a few; I'm not sure how you can view spray-painting buildings belonging to particular religious groups, punching your neighbors in the face, putting up "bigots live here" signage, etc as something other than "violent oppression". Of course you may be affected by your dislike for the targets of said oppression, but consider how we would view people spray-painting signs saying "Jews live here", say?
Now clearly only a small fraction of the "gay community" is involved in such acts. On the other hand, only a small fraction of opponents of gay marriage, say, is involved in violent acts. Neither is acceptable, and both are violent oppression in any meaningful sense of the word.
All of which comes down to the fact that any group that feels like it's in their power (either due to being a majority group or due to special protections from the government like the aristocracy in medieval Europe) will tend to violently oppress people it doesn't like. I wish it weren't so, but history and current events suggest that it is. What we should strive for is minimizing such incidents as much as we can, and NOT through making people shut up and conform.
The point is, they are. All sorts of stuff on the web doesn't work right if you try to use two browsers the way you describe. Now it may be that none of the sites you happen to use depend on the things that break, but you're not the only person out there.
You missed the third flaw: it was by-design incompatible with the existing HTML. That is, there was no reasonable migration path for authors. Not only that, but the working group involved went out of their way to make sure that xhtml2 couldn't be implemented in the same software as xhtml1 and HTML (culminating in reusing the xhtml1 namespace, while defining different semantics for the same tag names).
Basically, xhtml2 was an attempt to create a new World Wide Web that would be completely disjoint from the existing one: require a different browser, require separate authoring, etc. It failed, predictably, due to network effects; the existing web was too big and no one wanted to be the ones to drop support for it.
Why? A Flash instance on one page wants to change the state of a Flash instance on another page. The mechanism Flash uses for this only works if both instances are in the same process. Where does a FF problem come in?
> It would seem like that logic would apply to plugins too.
The Chrome folks tried it. Sites broke.
> There's little reason for unrelated web pages to share a plugin
Or a cookie store for subresources? Or a cache? Unfortunately, none of those statements happen to be false in practice... Witness all the sites that let you log in with your Google account, say; Flash has some similar things that require state to be maintained across all plug-in instances and maintains such state in its address space.
Now Flash could be changed to maintain the state in a broker process, but that would need to be a change in Flash.
> Then there are two instances of Flash in separate address spaces.
Yes, but you don't expect the pages you have loaded in IE to affect the ones you have loaded in Firefox. If you have a page loaded in Firefox and you click a link that opens a new window from that page, the new window can affect the page it was opened from. In particular, they can share Flash plugin state.
What flash needs for a lot of what it does is raw device access. In Linux terms, access to stuff in/dev (video, camera, audio, etc).
It's clearly possible to setuid Flash to a low-privileges user if you want it to not write to disk in general and don't mind breaking part of the functionality. The question is whether you're willing to break it. Browsers may not be in a position to do that (though you individually may be if you don't use certain Flash features yourself).
This is at least in part because on the 3.6 branch the 64-bit version is not at feature parity with the 32-bit one (for example doesn't have the JS jit, so has much worse JS execution performance). So linking to it on equal terms really doesn't make sense.
For 4.0, 64-bit Linux builds are much higher quality (for example they actually have the automated correctness tests run on them). So there's a decent chance those builds might become tier-1 by the time 4.0 ships.
You can, if you're willing to break enough sites... Flash commonly performs network access, raw graphics operations of various sort, file access, and a few other things like that which would have to be disallowed in a sandbox.
You're exactly right. Flash assumes that all running instances of it share a single address space and uses various internal communication channels to have the instances talk to each other. The Chrome folks actually tried a process per plugin instance, and it broke too much stuff out there.
> Building multi-core processors isn't easy and how many mobile phones do you know that are > sporting them?
Touch T5353 MTK, so far.
And various phone vendors are making noise about shipping multicore systems (based on Qualcomm's MSM8260 or ARM9 or MTK6516) by end of this year or so.
Then again, calling the devices involved "phones" is a bit of a stretch for me (just as much for an iPhone as for an N900).
> Software is NOT designed to be perfect and cover every case.
It really depends on the situation.
For example, the software that handles the US passport system needs to handle anything that can appear in a legal name in the US, since the name on the passport needs to be the legal name.
One would think that so should state drivers license systems, except the Massachusetts one, for example, doesn't allow a space in the last name. The consequence? It's technically not legal to use your MA license as ID to board a plane if you happen to have a space in your last name (because the name on the license is not your legal name). All thanks to people with attitudes like yours not bothering to think a bit more before coding in extraneous checks in their code.
> It's not terribly hard to build your own browser atop WebKit
Well, you just have to provide a networking library, a crypto library, a user interface, a cache, and a few other minor things like that.... How "hard" that is depends on whether you have those easily available and whether they play well with each other.
Looking at the actual parts involved according to wikipedia, the old mini had either a P7550 (2.26 GHz), P8700 (2.53 Ghz) or a P8800 (2.66 Ghz). The new one has a P8600 (2.4 GHz) or a P8800.
So looks like you're right and the 2.4Ghz model downgrade from the 2.53 GHz model processor-wise.
That's assuming that these are the same "Core 2 Duo"s. Unfortunately, that name can apply to a wide variety of processors, with pretty different performance characteristics even at the same clock speed (for one thing, the L2 cache sizes vary pretty widely).
> Well, clearly they use some other proposed specs as well, like CSS3, Webforms 2.0, > 3D CSS transforms, but I don't see anything that isn't a proposed Web standard.
As I said elsewhere in this thread, the bar for "proposed web standard" is very low if you mean "W3C working draft" by that. Pretty much any W3C member can create a proprietary extension to their product, lightly document it, and publish the result as a working draft. Most of these go nowhere. Claiming that they're a "spec" of any sort is just preying on people who don't understand how the W3C process works.
> Most people are lumping several technologies into the term "HTML5" in the press and > common usage.
More precisely, there has been an intensive media campaign by Google to so lump them together and expand the "HTML5" term to cover various proprietary extensions they're making to their browser (more or less trying to redefine "HTML5" to mean "whatever Chrome implements". Unfortunately, thanks to people like you, they're succeeding. So now Apple is feeling the need to do the same but with Safari.
> Please provide a specific quote and citation.
The apple site says: "This demo was designed with the latest web standards supported by Safari. If you'd like to experience this demo, simply download Safari." The obvious implications are: 1) What's used are standards (not proposals) and 2) your current browser doesn't support them. I don't know how the verbiage could actually be any clearer, really.
> since it demoes features HTML5 allows Safari to support
Not really. It just demoes features Safari supports, whether or not they have anything to do with HTML5. Which is fine, but calling that an "HTML5 Showcase" is bunk.
> What are you talking about? Both are under the purview of the WHATWG working group.
That's bunk. No part of CSS is under the purview of WHATWG except insofar as CSS specs say the document language determines how something works.
>>> is generally referred to as "HTML5" by both the layman and the people writing >>> the specs. >> >> Speaking as one of the latter... no, it's not. > > The last sentence of the first paragraph on the HTML5 wikipedia page reads: "In common > usage, HTML5 may also refer to the additional use of CSS3
Yes, the Apple and Google attempt to create confusion around the term has somewhat worked, especially thanks to people like you.
> Apparently you are not the average layperson.
I said "the latter" (as in, person writing the specs), not "the former" (which would have been layperson). Reading comprehension, please.
>> Well, since no CSS specs are whatwg specs... that's easy. > > Gee WHATWG disagrees on that.
I call bullshit. Citation, please?
> which has been a fully published working draft since early 2009
You seem to be under some misapprehension as to how working drafts work in the W3C. Anyone who's a working group member (which entails only ponying up money) can propose one. If it fits within the working group's charter, the bar to publication is very low. So any member can implement any proprietary extension, document it, and propose it for standardization by publishing a working draft describing it. What typically happens after that is that either other implementors get on board and implement and the draft proceeds along the standards track or competing proposals are made (say WebGL in this case), and then the competing proposals fight it out. There are plenty of working drafts around that were proposed unilaterally and never went anywhere. http://www.w3.org/TR/NOTE-AS is a good example (the competing proposal for that was CSS).
> with open source reference implementations.
3d transforms is only supported in Safari and only on certain Apple operating systems, because it's implemented by directly calling into the closed-source and proprietary Core Animation framework to actually do all the work. If you call that an "open source reference implementation", you either have a strange definition of "open source" or have no idea what you're talking about.
> Clearly they are trying to take over the Web and make it proprietary or something?
As a matter of fact, that's the only way to interpret some of the things they're doing with Mobile Safari, yes. They would like to control as much content delivery as they possibly can, on their own terms (and are actively encouraging development of content that only works in Mobile Safari and will continue to only work in Mobile Safari).
> Yeah, you're just a hater
Or perhaps you're just and underinformed apologist?
> The HTML behind the demos is very slim (as it should be)
Should it, for an "HTML5" demo? Especially if the HTML doesn't actually do anything? If it's actually a demo of scripting or proprietary CSS extensions or something else, then call it that.
Slashdot Mirror
> Expressing your opinion is one thing (name calling shouting, debating, etc.).
That depends. Under current law in many cases shouting at someone is in fact treated as a hate crime. Depends on who's doing the shouting and who's being shouted at. Not sure that's a good thing, mind you, but it's what the law says.
> ANYONE who violently oppress' someone else for their beliefs should be prosecuted as a
> "Hate Crime" regardless of who is doing the oppressing.
Fully agreed, except I'm not sure we need the "Hate Crime" bit. Just prosecute them for the actual illegal actions they took.
> The gay community isn't exactly going out of its way to violently oppress those who oppose
> it, while the other side can't say the same.
That depends on where you live and how you define "gay community". In California during the Proposition 8 debates and right after its passage there was quite a number of rather ugly incidents.
http://www.christianexaminer.com/Articles/Articles%20Dec08/Art_Dec08_09.html lists a few; I'm not sure how you can view spray-painting buildings belonging to particular religious groups, punching your neighbors in the face, putting up "bigots live here" signage, etc as something other than "violent oppression". Of course you may be affected by your dislike for the targets of said oppression, but consider how we would view people spray-painting signs saying "Jews live here", say?
Now clearly only a small fraction of the "gay community" is involved in such acts. On the other hand, only a small fraction of opponents of gay marriage, say, is involved in violent acts. Neither is acceptable, and both are violent oppression in any meaningful sense of the word.
All of which comes down to the fact that any group that feels like it's in their power (either due to being a majority group or due to special protections from the government like the aristocracy in medieval Europe) will tend to violently oppress people it doesn't like. I wish it weren't so, but history and current events suggest that it is. What we should strive for is minimizing such incidents as much as we can, and NOT through making people shut up and conform.
> Things aren't broken if I do that today
The point is, they are. All sorts of stuff on the web doesn't work right if you try to use two browsers the way you describe. Now it may be that none of the sites you happen to use depend on the things that break, but you're not the only person out there.
You missed the third flaw: it was by-design incompatible with the existing HTML. That is, there was no reasonable migration path for authors. Not only that, but the working group involved went out of their way to make sure that xhtml2 couldn't be implemented in the same software as xhtml1 and HTML (culminating in reusing the xhtml1 namespace, while defining different semantics for the same tag names).
Basically, xhtml2 was an attempt to create a new World Wide Web that would be completely disjoint from the existing one: require a different browser, require separate authoring, etc. It failed, predictably, due to network effects; the existing web was too big and no one wanted to be the ones to drop support for it.
> That sounds like a problem with FF, not Flash.
Why? A Flash instance on one page wants to change the state of a Flash instance on another page. The mechanism Flash uses for this only works if both instances are in the same process. Where does a FF problem come in?
> It would seem like that logic would apply to plugins too.
The Chrome folks tried it. Sites broke.
> There's little reason for unrelated web pages to share a plugin
Or a cookie store for subresources? Or a cache? Unfortunately, none of those statements happen to be false in practice... Witness all the sites that let you log in with your Google account, say; Flash has some similar things that require state to be maintained across all plug-in instances and maintains such state in its address space.
Now Flash could be changed to maintain the state in a broker process, but that would need to be a change in Flash.
> Then there are two instances of Flash in separate address spaces.
Yes, but you don't expect the pages you have loaded in IE to affect the ones you have loaded in Firefox. If you have a page loaded in Firefox and you click a link that opens a new window from that page, the new window can affect the page it was opened from. In particular, they can share Flash plugin state.
3.7 got renumbered. It will be released as 4.0.
> However processes use a lot more memory
Depending on how you measure, they can, yes.
> Also, the browser should not crash
Sure would be nice! ;)
> I'm not sure the security added by sandboxing tabs into processes is worth the trouble
> right now.
Why not? It's as effective an exploit-mitigation strategy as anything else out there. Reduces attack surface, etc...
What flash needs for a lot of what it does is raw device access. In Linux terms, access to stuff in /dev (video, camera, audio, etc).
It's clearly possible to setuid Flash to a low-privileges user if you want it to not write to disk in general and don't mind breaking part of the functionality. The question is whether you're willing to break it. Browsers may not be in a position to do that (though you individually may be if you don't use certain Flash features yourself).
This is at least in part because on the 3.6 branch the 64-bit version is not at feature parity with the 32-bit one (for example doesn't have the JS jit, so has much worse JS execution performance). So linking to it on equal terms really doesn't make sense.
For 4.0, 64-bit Linux builds are much higher quality (for example they actually have the automated correctness tests run on them). So there's a decent chance those builds might become tier-1 by the time 4.0 ships.
You can, if you're willing to break enough sites... Flash commonly performs network access, raw graphics operations of various sort, file access, and a few other things like that which would have to be disallowed in a sandbox.
You're exactly right. Flash assumes that all running instances of it share a single address space and uses various internal communication channels to have the instances talk to each other. The Chrome folks actually tried a process per plugin instance, and it broke too much stuff out there.
> For performance reasons, tabs don't and shouldn't run in separate processes.
In both IE8 and Chrome, tabs do in fact run in separate processes, with some caveats.
> On most platforms, processes are more expensive than threads
While true, processes have the benefits that:
Threads don't have those two properties, and both IE8 and Chrome actually make use of them.
> Building multi-core processors isn't easy and how many mobile phones do you know that are
> sporting them?
Touch T5353 MTK, so far.
And various phone vendors are making noise about shipping multicore systems (based on Qualcomm's MSM8260 or ARM9 or MTK6516) by end of this year or so.
Then again, calling the devices involved "phones" is a bit of a stretch for me (just as much for an iPhone as for an N900).
> Software is NOT designed to be perfect and cover every case.
It really depends on the situation.
For example, the software that handles the US passport system needs to handle anything that can appear in a legal name in the US, since the name on the passport needs to be the legal name.
One would think that so should state drivers license systems, except the Massachusetts one, for example, doesn't allow a space in the last name. The consequence? It's technically not legal to use your MA license as ID to board a plane if you happen to have a space in your last name (because the name on the license is not your legal name). All thanks to people with attitudes like yours not bothering to think a bit more before coding in extraneous checks in their code.
> Hm, are you sure?
I was, but it looks like people have been adding stuff into the webkit repository.
> WebKit is built on top of both CFLite, which includes networking classes.
It doesn't quite have an HTTP implementation, say.... at least that I can find.
> I'm also pretty sure WebKit includes a caching engine too.
Looks like there is one now, yes. It's interesting that Chrome doesn't use it (and I'm not sure Safari does either, but of course it's hard to tell).
> I see a lot of tutorial's like this around the net the implement none of the things you
> say need to be implemented:
Though this does rely on the particular gtk webkit widget (which is not necessarily great for a nominally cross-platform app like Flock).
> It's not terribly hard to build your own browser atop WebKit
Well, you just have to provide a networking library, a crypto library, a user interface, a cache, and a few other minor things like that.... How "hard" that is depends on whether you have those easily available and whether they play well with each other.
Yes, of course. See the discussion you're replying to.
Ah, indeed.
Looking at the actual parts involved according to wikipedia, the old mini had either a P7550 (2.26 GHz), P8700 (2.53 Ghz) or a P8800 (2.66 Ghz). The new one has a P8600 (2.4 GHz) or a P8800.
So looks like you're right and the 2.4Ghz model downgrade from the 2.53 GHz model processor-wise.
That's assuming that these are the same "Core 2 Duo"s. Unfortunately, that name can apply to a wide variety of processors, with pretty different performance characteristics even at the same clock speed (for one thing, the L2 cache sizes vary pretty widely).
> even though they should already be by default
Why should they be, exactly? What's special about churches that's not special about other clubs, associations, etc?
> Well, clearly they use some other proposed specs as well, like CSS3, Webforms 2.0,
> 3D CSS transforms, but I don't see anything that isn't a proposed Web standard.
As I said elsewhere in this thread, the bar for "proposed web standard" is very low if you mean "W3C working draft" by that. Pretty much any W3C member can create a proprietary extension to their product, lightly document it, and publish the result as a working draft. Most of these go nowhere. Claiming that they're a "spec" of any sort is just preying on people who don't understand how the W3C process works.
> Most people are lumping several technologies into the term "HTML5" in the press and
> common usage.
More precisely, there has been an intensive media campaign by Google to so lump them together and expand the "HTML5" term to cover various proprietary extensions they're making to their browser (more or less trying to redefine "HTML5" to mean "whatever Chrome implements". Unfortunately, thanks to people like you, they're succeeding. So now Apple is feeling the need to do the same but with Safari.
> Please provide a specific quote and citation.
The apple site says: "This demo was designed with the latest web standards supported by Safari. If you'd like to experience this demo, simply download Safari." The obvious implications are: 1) What's used are standards (not proposals) and 2) your current browser doesn't support them. I don't know how the verbiage could actually be any clearer, really.
> since it demoes features HTML5 allows Safari to support
Not really. It just demoes features Safari supports, whether or not they have anything to do with HTML5. Which is fine, but calling that an "HTML5 Showcase" is bunk.
> What are you talking about? Both are under the purview of the WHATWG working group.
That's bunk. No part of CSS is under the purview of WHATWG except insofar as CSS specs say the document language determines how something works.
>>> is generally referred to as "HTML5" by both the layman and the people writing
>>> the specs.
>>
>> Speaking as one of the latter... no, it's not.
>
> The last sentence of the first paragraph on the HTML5 wikipedia page reads: "In common
> usage, HTML5 may also refer to the additional use of CSS3
Yes, the Apple and Google attempt to create confusion around the term has somewhat worked, especially thanks to people like you.
> Apparently you are not the average layperson.
I said "the latter" (as in, person writing the specs), not "the former" (which would have been layperson). Reading comprehension, please.
>> Well, since no CSS specs are whatwg specs... that's easy.
>
> Gee WHATWG disagrees on that.
I call bullshit. Citation, please?
> which has been a fully published working draft since early 2009
You seem to be under some misapprehension as to how working drafts work in the W3C. Anyone who's a working group member (which entails only ponying up money) can propose one. If it fits within the working group's charter, the bar to publication is very low. So any member can implement any proprietary extension, document it, and propose it for standardization by publishing a working draft describing it. What typically happens after that is that either other implementors get on board and implement and the draft proceeds along the standards track or competing proposals are made (say WebGL in this case), and then the competing proposals fight it out. There are plenty of working drafts around that were proposed unilaterally and never went anywhere. http://www.w3.org/TR/NOTE-AS is a good example (the competing proposal for that was CSS).
> with open source reference implementations.
3d transforms is only supported in Safari and only on certain Apple operating systems, because it's implemented by directly calling into the closed-source and proprietary Core Animation framework to actually do all the work. If you call that an "open source reference implementation", you either have a strange definition of "open source" or have no idea what you're talking about.
> Clearly they are trying to take over the Web and make it proprietary or something?
As a matter of fact, that's the only way to interpret some of the things they're doing with Mobile Safari, yes. They would like to control as much content delivery as they possibly can, on their own terms (and are actively encouraging development of content that only works in Mobile Safari and will continue to only work in Mobile Safari).
> Yeah, you're just a hater
Or perhaps you're just and underinformed apologist?
Display PDF can change the text layout on the fly as you resize the horizontal available space?
> The HTML behind the demos is very slim (as it should be)
Should it, for an "HTML5" demo? Especially if the HTML doesn't actually do anything? If it's actually a demo of scripting or proprietary CSS extensions or something else, then call it that.