No, the fundamental difference is that the average consumer wants to send self-executing greeting cards, videos, and interactive multimedia nonsense. Although MS could tighten security, the bottom line is that the consumer does not want to learn, nor cares about, chmod.
Indeed, and perhaps this is an opportunity for Linux/Unix to be marketed as a "Corporate" rather than a "Consumer" OS. In a corporate setting such 'multimedia nonsense' is a headache, not a bonus.
But a fundamental difference on Unix type systems is that files aren't inherantly executable based simply on their extension, someone can't just save a file from their email and execute it, they need to know at least enough to "chmod u+x" the file which should at least make them think about it.
Of course, that doesn't mean it's impossible to make an email client or desktop environment that would launch an attachment with "/usr/bin/sh" but hopefully that is so blindingly stupid that no-one would do it.
While it might be natural for someone like Dean Kamen, the problem is that the way it works is totally unlike that of a bicycle, let alone a skateboard.
That's not a problem, that's the good bit. Neither bicycles nor skateboards are intrinsically easy to ride, they take a great deal of practice. The hardest part of learning either is learning how to avoid falling on your arse. With the Segway the vehicle itself takes care of that.
was that of the 11 people who voted and who have gnu.org email addresses only 2 people, including RMS, voted for RMS.
Not that this necessarily means anything particularly significant, I have no idea about what having a gnu.org email address means for a start, it's just vaguely interesting.
That's the thing that concerns me. There's something about this that smells more like passing the buck than sharing the wealth. If the adoption percentages are significantly lower than my guesstimates
IBM have invested in Linux people. A kernel-hacking friend of mine was picked up by them shortly after the Linuxcare/Turbo Linux merger. It makes sense for them spend resources to get the kernel and other pieces of software to work better on their hardware. It doesn't make a great deal of sense for them to attempt to get across the vast diversity of generalised support issues.
People downloading kernels from kernel.org, particularly in the first few days of a release, are part of the QA process, not the ultimate beneficiaries of one.
The Open Source (or more correctly, bazaar or distributed) development model also distributes responsibility. If the possibility of losing your data is something you can't afford then you simply shouldn't be sitting on the cutting edge of kernel development.
Well screw the politics. GNU is offering you freedom in your software. Nobody's forcing you to take it.
They're not in a position to. But I'm sure they'd like to be. If you read the article it clearly states that they do not advocate the freedom to choose non-Free licences. They don't think this is a freedom at all, but the opposite. If they were in a position to require Free licences they surely would be doing it.
RMS even wants the GNOME project to not mention proprietary software as a matter of policy. If that isn't an attempt at censorship for political reasons I don't know what is.... It's actions such as these that "moderates" may find offensive.
Currently the only disagreement that I'm aware of between RMS and the GNOME foundation is the mentioning of the (non-free, but free software related) Star Office application suite some time back. This caused RMS to ask for a policy decision to never mention non-free software. (Does this mean that it would be no longer possible to announce that Sun have released GNOME packages for non-free Solaris?) Does this help in any way the goal of creating an entirely free desktop environment for free systems? I sincerely doubt it.
The GNOME Foundation board should focus on facilitating interested parties (individual or corporate) create free software for the GNOME desktop. They should not be making it more onerous for these interested parties by creating policy for the sake of policy.
Maybe remove the "all third parties" bit?
It brings up the question of who the first and second parties are. If the first party is the originating author and the second party is the creator of the derivative work the the creator of the derivative work could presumably licence it to the originating author under any licence.
Software or movie it's all just data. Software or movie that data is interpretted (in some sense of the word) by another software/firmware/hardware combination to provide some form of output. On that side of the equation the two are largely inseperable.
However I think a key factor is considering how the data is created. On the software side you have a piece of data which is the logically exact representation of that data's source. It is a definitive rendition. On the movie side (analogue or digital) that is not true. The data is an approximation of the original, not a logically definitive rendition of it.
In short anything that is being pushed through a lossy process and be still expected to "work" cannot be considered software as software does not tolerate such lossyness (if that's a word).
Note: In CSS1 & CSS2 the form elements of HTML were also counted as replaced elements, because they were considered to be replaced by buttons, text fields, etc. that were proprietary to the platform. In CSS3 these elements are normal, non-replaced elements. CSS3 has explicit properties that can make them look like they did in CSS1 and CSS2 (or make them look completely different).
So there you are. If you are building a browser that hopes to be and continue to be "state of the art" you better treat your standard form elements as you would any other element, because while buttons etc may look like they did previously they can also be made to look completely different using standard CSS terminology as with any other element.
Native widgets on both Windows and Mac have transparent backgrounds and draw in a z-ordered way.
How nice. What a pity that the CSS3 proposal covering opacity doesn't just call for transparent backgrounds but for whole elements (including content) to be transparent. To my knowledge the windows widgets don't support that natively. I'm happy to be proved wrong though, show me some source code that I can compile and run on win98 or an msdn page that says otherwise.
Re:Native OS widgets cannot be used if you want CS
on
Netscape 6.2
·
· Score: 2
Are you trolling? I'm beginning to conclude that you must be as you are misinterpreting virtually everything. HTML (in it's modern form) defines structural functionality.
CSS defines presentational possibilities.
The User Agents default stylesheet provides default CSS presentational definitions for HTML.
These defaults are overridable by the author and user (in that order) in accordance with the possibilities that CSS allows.
No offense, but that's just not true. An interactive element is not an empty DIV. It has a content area. That content area contains a button.
Er, that div wasn't empty, it had exactly the same content as the button. That content was the text "hello". To suggest that the content of a <button> element is the visual rendering of a button demonstrates a fundamental lack of understanding. The content of a <button> element is what lies between the two tags, as the html 4.01 specification shows quite plainly by placing some text and an image in there.
You seem to be fundamentally unaware of the evolution that this media has and is going through. Everything is being generalised. The presentational details (ie what it looks like) are being seperated from the structural functionality. That a button performs an action when clicked on is to do with it's structural functionality. That it looks like you'd expect a button to look is a presentational detail. With CSS, in a CSS compliant browser, an author (or user) can modify that look from the default look provided by the user agents default stylesheet in any way they like. In the same way it is possible to make a normally inline <span> element have a "display:block;" I can make a normally "inline-block" <button> element display with "inline", "block" , "table", "table-cell", "hidden" etc etc. Whether it makes sense for me to do so is another matter entirely, but it is possible and ultimatly required by the specs.
Everything is being generalised. Presentation is being seperated from structural functionality.
We're moving from html whatever to xhtml 1.1 (and beyond). Odd things (such as form widget rendering) that just "worked" in older HTML versions are being redefined in terms of generic CSS language (this is the goal of the CSS3 page I linked to if you read it). This generalisation opens a whole world of possibilities. If you are building a browser today and you want it to be able to grow into these possibilities you need to embrace the genericism from the ground up.
The whole bit you quoted after "explicitly says that backgrounds should not be set for HTML items" simply means that if you want to set a background for an HTML page (as opposed to a non-HTML XML page) they recommend you do it on the <body> element rather than the <html>. If you were styling an arbitrary XML page you'd set the background for the whole page on the root element. They are simply saying that for html you should do it on the <body> tag instead, largely for historical reasons. It's got absolutely nothing to do with buttons or widgets.
The goal there is to be able to use system default appearances, not to get away from system default appearances.
"system standard rendering" is not defined anywhere that I could find. Those keywords only give you access to system standard renderings. It would be a good idea for a user agent to make use of these definitions in it UA stylesheet. You are certainly not forced to use them as an author or as a user. As either a conforming browser would enable me to make a checkbox look like a radio button and vice versa, or stick something that looks like a radio button at the beginning of every paragraph.
Even if you accept that "system standard rendering" means using the default OS widgets and also accept that those widgets may not be capable of fulfilling other (potential) CSS aspects (z-index, opacity) then the specs are at odds with themselves and need to be fixed or priorities given. If I were allocating priorities I'd opt for consistancy within the browser window, rather than between the browser window and the OS.
Again, for those who have trouble reading spec language, that says that CSS3 is meant to use default system widget appearances, and that Mozilla is not going to be able to support CSS3 because it uses its own non-standard widget appearances.
I guess that depends on what you mean by platform. Mozilla could well be described as the platform. In any case people who don't have trouble reading W3 spec language are well aware that anything that is merely "suggested" has no impact on conformity to the standard. .
Some thoughts on the whole widget thing from the Mozilla folk are here.
Re:Native OS widgets cannot be used if you want CS
on
Netscape 6.2
·
· Score: 2
These are not correct interpretations of CSS. Background image and color are not the same as fill image and color, which is how these specifications are being interpreted in Mozilla. The background image of a button, for instance, is the image on which the button sits, not a fill image contained within a button.
I'd argue that you are incorrect, there is no concept of 'fill color' in css. As far as CSS is concerned a button element is nothing but a container. There is no difference to CSS whether I have:
=====
<button>hello</button>
=====
or
=====
<div>hello</div>
=====
except that user agents are more than likely to have default style rules that make a button look like a button (ie have borders that make it look raised normally or depressed when active and have a predefined background colour rather than being transparent as a div would be by default.)
Similarly an:
<input type=text value=hello>
is just a container that has a default style rule similar to:
======
input[type=text]{
content(content: attr(value);
background-color: etc;
border-top : etc etc
etc
}
======
The elements are just containers like any other, they are not inherantly special because they are "buttons". It may look like a button but to CSS it's just a box. Having said all that, current CSS recomendations may not be able to adequatly describe the visual rendering of all form elements but that is where we are heading. Ultimatly while form elements may normally look like they've been rendered with this style sheet there's nothing to stop the web author or end user modifying those attributes as they can any other attributes on any other element.
Re:Native OS widgets cannot be used if you want CS
on
Netscape 6.2
·
· Score: 2
Can you name a single specific example of a CSS requirement that can't be met by native widgets on Windows and Mac?
Not personally, no. I'm basing my assertion on comments I have read from both Opera and Mozilla developers. I have nothing but a passing familiarity with native widgets on Windows from a programming sense and no familiarity at all with the Mac.
If you can, you'll be the first since these discussions started, over two years ago IIRC.
Can everything at this site? Another issue is future CSS requirements. There's little point in going down the native widget path if you've got to throw the whole lot out and start again when opacity (for example) turns up in a recommendation.
Re:Native OS widgets cannot be used if you want CS
on
Netscape 6.2
·
· Score: 2
Well, as an app developer (at least if you develop gui apps on Windows) you may be in a better position to tell me:) Can everything here be done with native widgets for example? On the whole Mozilla seems to render the widgets on that page better than IE. Opera, which does use native widgets, misses most of the CSS stuff, though you can see they've mapped colours etc to the native widgets where the native widgets allow.
Native OS widgets cannot be used if you want CSS
on
Netscape 6.2
·
· Score: 2
Even IE uses it's own widget set (of course, in more recent versions of Windows, IE's widgets may now be the core widgets OS widgets).
The widgets provided by the OS in 95/NT simply are not capable of being styled in the way CSS demands.
Slashdot Mirror
in the "Name that tune" section of bar quizzes.
Not in the "mathematically simple" sense, but in the "of little worth or importance" sense.
But a fundamental difference on Unix type systems is that files aren't inherantly executable based simply on their extension, someone can't just save a file from their email and execute it, they need to know at least enough to "chmod u+x" the file which should at least make them think about it.
Of course, that doesn't mean it's impossible to make an email client or desktop environment that would launch an attachment with "/usr/bin/sh" but hopefully that is so blindingly stupid that no-one would do it.
than one of the people involved in allowing the very exploits you want to exploit to exist in the first place?
;)
in the case of my Palm VX.
was that of the 11 people who voted and who have gnu.org email addresses only 2 people, including RMS, voted for RMS.
Not that this necessarily means anything particularly significant, I have no idea about what having a gnu.org email address means for a start, it's just vaguely interesting.
People downloading kernels from kernel.org, particularly in the first few days of a release, are part of the QA process, not the ultimate beneficiaries of one.
The Open Source (or more correctly, bazaar or distributed) development model also distributes responsibility. If the possibility of losing your data is something you can't afford then you simply shouldn't be sitting on the cutting edge of kernel development.
so they can be cool and trendy and be on the development tree while it's still stable?
RMS even wants the GNOME project to not mention proprietary software as a matter of policy. If that isn't an attempt at censorship for political reasons I don't know what is.... It's actions such as these that "moderates" may find offensive.
I guess the (small) difference I'm seeing is the difference between "to create an entirely free desktop environment for free systems" and "to support the principle of software freedom". One of these seems practical, the other political.
Currently the only disagreement that I'm aware of between RMS and the GNOME foundation is the mentioning of the (non-free, but free software related) Star Office application suite some time back. This caused RMS to ask for a policy decision to never mention non-free software. (Does this mean that it would be no longer possible to announce that Sun have released GNOME packages for non-free Solaris?) Does this help in any way the goal of creating an entirely free desktop environment for free systems? I sincerely doubt it.
The GNOME Foundation board should focus on facilitating interested parties (individual or corporate) create free software for the GNOME desktop. They should not be making it more onerous for these interested parties by creating policy for the sake of policy.
The role of someone on the GNOME Board of Directors is to represent the best interests of the GNOME project not the interests of any other third party. Can RMS make this distinction?
Maybe remove the "all third parties" bit?
It brings up the question of who the first and second parties are. If the first party is the originating author and the second party is the creator of the derivative work the the creator of the derivative work could presumably licence it to the originating author under any licence.
Maybe.
Software or movie it's all just data. Software or movie that data is interpretted (in some sense of the word) by another software/firmware/hardware combination to provide some form of output.
On that side of the equation the two are largely inseperable.
However I think a key factor is considering how the data is created. On the software side you have a piece of data which is the logically exact representation of that data's source. It is a definitive rendition. On the movie side (analogue or digital) that is not true. The data is an approximation of the original, not a logically definitive rendition of it.
In short anything that is being pushed through a lossy process and be still expected to "work" cannot be considered software as software does not tolerate such lossyness (if that's a word).
It didn't take off with the scramjet, it took off using a rocket. The scramjet experiment was supposed to fire at a later stage.
From here:
So there you are. If you are building a browser that hopes to be and continue to be "state of the art" you better treat your standard form elements as you would any other element, because while buttons etc may look like they did previously they can also be made to look completely different using standard CSS terminology as with any other element.
How nice. What a pity that the CSS3 proposal covering opacity doesn't just call for transparent backgrounds but for whole elements (including content) to be transparent. To my knowledge the windows widgets don't support that natively. I'm happy to be proved wrong though, show me some source code that I can compile and run on win98 or an msdn page that says otherwise.
HTML (in it's modern form) defines structural functionality.
CSS defines presentational possibilities.
The User Agents default stylesheet provides default CSS presentational definitions for HTML.
These defaults are overridable by the author and user (in that order) in accordance with the possibilities that CSS allows. Er, that div wasn't empty, it had exactly the same content as the button. That content was the text "hello". To suggest that the content of a <button> element is the visual rendering of a button demonstrates a fundamental lack of understanding. The content of a <button> element is what lies between the two tags, as the html 4.01 specification shows quite plainly by placing some text and an image in there.
You seem to be fundamentally unaware of the evolution that this media has and is going through. Everything is being generalised. The presentational details (ie what it looks like) are being seperated from the structural functionality. That a button performs an action when clicked on is to do with it's structural functionality. That it looks like you'd expect a button to look is a presentational detail.
With CSS, in a CSS compliant browser, an author (or user) can modify that look from the default look provided by the user agents default stylesheet in any way they like.
In the same way it is possible to make a normally inline <span> element have a "display:block;" I can make a normally "inline-block" <button> element display with "inline", "block" , "table", "table-cell", "hidden" etc etc. Whether it makes sense for me to do so is another matter entirely, but it is possible and ultimatly required by the specs.
Everything is being generalised. Presentation is being seperated from structural functionality. We're moving from html whatever to xhtml 1.1 (and beyond). Odd things (such as form widget rendering) that just "worked" in older HTML versions are being redefined in terms of generic CSS language (this is the goal of the CSS3 page I linked to if you read it). This generalisation opens a whole world of possibilities. If you are building a browser today and you want it to be able to grow into these possibilities you need to embrace the genericism from the ground up.
The whole bit you quoted after "explicitly says that backgrounds should not be set for HTML items" simply means that if you want to set a background for an HTML page (as opposed to a non-HTML XML page) they recommend you do it on the <body> element rather than the <html>. If you were styling an arbitrary XML page you'd set the background for the whole page on the root element. They are simply saying that for html you should do it on the <body> tag instead, largely for historical reasons. It's got absolutely nothing to do with buttons or widgets.
"system standard rendering" is not defined anywhere that I could find.
Those keywords only give you access to system standard renderings. It would be a good idea for a user agent to make use of these definitions in it UA stylesheet. You are certainly not forced to use them as an author or as a user. As either a conforming browser would enable me to make a checkbox look like a radio button and vice versa, or stick something that looks like a radio button at the beginning of every paragraph.
Even if you accept that "system standard rendering" means using the default OS widgets and also accept that those widgets may not be capable of fulfilling other (potential) CSS aspects (z-index, opacity) then the specs are at odds with themselves and need to be fixed or priorities given. If I were allocating priorities I'd opt for consistancy within the browser window, rather than between the browser window and the OS.
I guess that depends on what you mean by platform. Mozilla could well be described as the platform. In any case people who don't have trouble reading W3 spec language are well aware that anything that is merely "suggested" has no impact on conformity to the standard.
.
Some thoughts on the whole widget thing from the Mozilla folk are here.
=====
<button>hello</button>
=====
or
=====
<div>hello</div>
=====
except that user agents are more than likely to have default style rules that make a button look like a button (ie have borders that make it look raised normally or depressed when active and have a predefined background colour rather than being transparent as a div would be by default.)
Similarly an: <input type=text value=hello> is just a container that has a default style rule similar to:
======
input[type=text]{
content(content: attr(value);
background-color: etc;
border-top : etc etc
etc
}
======
The elements are just containers like any other, they are not inherantly special because they are "buttons". It may look like a button but to CSS it's just a box. Having said all that, current CSS recomendations may not be able to adequatly describe the visual rendering of all form elements but that is where we are heading. Ultimatly while form elements may normally look like they've been rendered with this style sheet there's nothing to stop the web author or end user modifying those attributes as they can any other attributes on any other element.
Well, as an app developer (at least if you develop gui apps on Windows) you may be in a better position to tell me :) Can everything here be done with native widgets for example? On the whole Mozilla seems to render the widgets on that page better than IE. Opera, which does use native widgets, misses most of the CSS stuff, though you can see they've mapped colours etc to the native widgets where the native widgets allow.
Even IE uses it's own widget set (of course, in more recent versions of Windows, IE's widgets may now be the core widgets OS widgets). The widgets provided by the OS in 95/NT simply are not capable of being styled in the way CSS demands.