" When will people realize they don't have a "right" to be hosted?"
If you have agreed a contract, abide by the T&Cs, and keep up payment; you have a RIGHT to be hosted, unless the contract is ended under its own T&Cs...
Fair comment, though I can think of places where similar features are desirable -> changing product images is a better usage.
"Useful from a commercial point of view. Really rather distracting from a visitor point of view. If I can't block it, I'm likely to find another vendor."
Good luck; sites designed to sell tend to ADVERTISE their wares. You seem to be thinking 3-second rotation; I'm thinking more 1-minute rotation of current "specials". Put bluntly; I have clients that will pay me to do this if its possible.
"This sounds practical, but at some stage you need to send the user to a new page anyway, and you can calculate new totals without having to make server calls."
1; I don't want the mechanism for calculations at the client side, so the calculation would require a reload, therefore this will make the page more responsive; i.e. better. The reason for non-client side? First: javascript is a shit language for anything other than DOM manipulation. Second: clients don't want their business logic exposed in javascript. Third: we don't want to download all the data required for those calculations to the client (prices in a code-manipulatable form should NEVER get to the client side, or be sent via post/get, prices just get displayed to the client, not manipulated by them)
Think about a checkout that calculates shipping costs globally; you need the location from the client. Depending on location the methods available for shipping will change. Depending on weight of goods (changes with quantity change) and location, the costs for each method change.
Thats a LOT of information to download to the client's machine to make the totals update without a server-call. Its also a ton of information (including prices) that I don't want the client side to have access to, and that I don't want javascript responsible for calculations on.
If I can pull down just the new value, rather than the whole page -> better!
"Ummm... why would you want an RSS new ticker on a webpage in the first place?"
Again; clients will pay for it. Just because YOU don't want it (or, in fact, that my client's clients don't want it), doesn't mean it has no value.
"Yes, lets just create something with no practical advantages over Flash/Iframe, but which requires a more recent browser to access."
There are plenty of advantages to not using flash. (reduce number of languages required to display 1 page and reduce number of external plugins required to display 1 page to name just 2 advantages)
Iframes are never a good idea.
And did you read the list of supported browsers? Only notable omission in the real world was safari... 2;
repopulate your product page for a new product WITHOUT reloading the whole page.
Put a timer in, and have rotating feature products WITHOUT reloading the whole page on a timer.
Update your totals in your chckout / shopping cart WITHOUT reloading the whole page.
Write an RSS news ticker in html rather than flash...
Basically anything that you might have used flash or an IFrame for, you could do with this, javascript and a DIV tag... Pretty important news (if you write commercial websites)
In fact, I think "class" would be the correct attribute. It defines a type for an element, which can be used by CSS, but is not necessarily limited to that. Elements can also have more than one class value (e.g. class='nofollow external_link' etc)
The fact that you don't necessarily use the nofollow class in your CSS is not a problem (and you can always style nofollow links differently should you wish...
To my mind it _might_ be a good thing if the rampant speed-advance slowed (a lot).
Consider:
We might get some return to efficient coding being the norm, instead of writing systems anyhow and throwing more/faster hardware at it until it runs acceptably (Microsoft; its you I'm looking at!)
Your (and your business') desktop machine might _not_ become obsolete in no more than 2 years, and mmight continue in useful service as something more sensible than a whole PC doing the job of a router...
Processor designers might spend more time (i know they already spend some) on innovating new ideas, rather than solving the problems with just ramping up clock speeds.
Cooling/Quietening technology might have a snowball's chance in hell of catching up with heat output?
(and the wild dreaming one) Games writers might remember about gameplay, rather than better coloured lighting...
In time, certainly, good companies will come to measure success in terms of successful litigation.
We are in the here and now; and that is PATENTLY not what current legal departments are aiming at. They are very evidently "trigger happy" at the moment.
Costly losses, or embarrassing negative publicity from their over-eagerness is required to _sink in_ to upper management's minds before the goal will change.
Basically if SCO (etc) lose, badly, and either go bankrupt or see (the last few in SCO's case)investors vanish, other companies will begin to think a little more about firing off a law suit "because we can", or "because the other guy will probably cave".
How much have constant losses slowed the MPIAA/RIAA's flood of suits?
I think this reinforces two lessons of the early 21st century:
There is no such thing as a "nice" company.
There is no such thing as a responsible legal department.
(Companies, after all exsit to do _nothing_ but make money, legal departments can only demonstrate their performance in "amount of litigation participated in" - Its a brave new world, friends!)
Browsers get fed, essentially, random data from untrusted sources. To produce an inherently stable and secure browser, ALL data should be treated as broken and/or malicious until shown to be otherwise.
A key test would be; construct a large (2-3 Gigs) file full of mostly valid, but partially malformed / misaligned HTML/xhtml. Feed that to the browser.
It shouldn't crash, it _should_ gracefully decline to continue once it either runs low on resource, or gets stuck on nonsense markup. It should then release the resource, and you should be able to continue.
I doubt ANY current browser could pass that test.
And no, thats not a sensible real-world test. The best QA tests aren't; you test for the unreasonable to (to some degree) assure yourself the resonable will be OK. (I used to do QA, and that IS how you do it right...)
Browser uses standard HTML/xhtml/xml format for its bookmarks.
Browser is capable of using this file from anywhere, including through http, or from a local file.
Bookmark management is still done through the browser interface, but the location of the bookmarks becomes browser independant.
For the http version, you would want a simple server side script to handle through http requests all the bookmark management (edit/add/delete/move around etc). There is no reason for this to be a complex script; you could put it on your own site, or have it on a central site, it should be your choice. You can even SSL and/or password protect your bookmarks, should you need to.
This simple system could even (gosh!) be cross browser and cross platform (its only an xml file, all it needs is a standard format, developed independant of each browser and then used by some or all)
This would give you bookmarks that could be accessed from multiple machines no problem.
For those who don't want http bookmarks, its just an xml file; put it on a floppy disk, USB flash drive or even your bluetooth mobile phone and take your bookmarks with you when you travel.
By default the browser just uses a local file in its app directory, so no visible change for those who _don't_ want common bookmarks.
All common sense. All great for the end user. Will never get implemented by ANY browser ever, I'll bet you:(
Get a modern decent browser; both Safari on my Mac, and Firefox on all of my PCs offer "Save this password: Yes? No? Never for this site?" or wording and options to that effect.
A large proportion of the BBC's and a fair proportion of Channel 4's current history educational programming is presented by real academics. Not necessarily "professors" (which is a specific academic-arena job, not entirely related to qualifications), but real academics.
Think of most of the history programs where you see the presenter, instead of hearing a narrator; plenty of those presenters have "proper" academic jobs. IIRC, even the "what the victorians did for us" guy, despite his silly costumes etc, is a pretty highly qualified man...
By my recollection, the "golden age" you referred to consisted mostly of leather-elbow-pad wearing crusties with a blackboard on the Open University. And they didn't represent any golden age of educational programming to my mind...
(educational programming, at its best, presents real and somewhat accurate information, but does so in an engaging manner; neither half of the package is optional)
"File managers do not have any higher access to the filesystem than the web browser already does."
Bullshit.
A browser has NO need to have rights to copy or delete files that it did not create. And it only need rights to create its own files in specific places.
By definition a File Manager needs to be able to copy and delete arbitrary files in the file system, otherwise you cannot Manage your Files with it.
There is no legitimate need for the two requirements to be brought together, and the fact that they end up co-existing in the same (externally scriptable, by definition as a web browser) leads to security risks.
" Lets make a deal: it is a bug in the security implementation of Java by Sun. Sheesh. That's what I said, didn't I?"
I think you read an implied slur into me simply having chosen to use the word "java" instead of "sun" when paraphrasing instead of actually quoting you. None was intended.
On to the point; as I recall the 2 main problems with ActiveX security are:
1; the browser (IE being _the_ ActiveX browser IIRC) pushes "security" options such as "allow signed scripts to run". Johnny Hacker is quite capable of signing his code, thus getting it run without question on most installs.
2; it is quite plausible to spoof your signature. Then even if you are requiring manual authentication of each signature before you let it run, it may well look to the casual user like a macromedia or Microsoft signature, and therefore it gets run.
Contrast with the (intention of the) Java security model, where it is not supposed to be possible to GET the kind of access that allows destruction / subversion in the first place.
Its the (piss-weak) "security" attitude that "if company X wants access that would let it format your drives, but only after scanning all the files on them, then its OK, because its company X, isn't it?" that is the problem with ActiveX.
No "program" run through your browser has legitimate need to that level of access to your local machine.
My personal opinion is that there are 2 fundamental flaws in how some companies view "browsers":
1 - they think that the web browser and the file manager shouyld become one.
2 - they think that goal justifies tying the browser tightly to the file system on the local machine, and justifies including low-level local access mechanisms into the browser and the things it can browse.
Personally I disagree; I think that having any "web format" of data/program able to escalate its rights to that kind of level is suicidal in terms of security, and therefore the risks of the required infrastructure make having your web browser serve to handle your local file system vastly outweight the minimal benefit of dropping one program from the machine.
I also think that may have been the longest sentence I've ever written; so I'll preserve it for posterity!
The "patch before admitting the problem" thing DOES happen on Windows.
But when it happens on windows it is microsoft "covering up their vulnerabilities".
Apparently, for you, when someone else does it they are doing something good...
Security by Obscurity, no matter who does it, it is still bad. Just because the WHOLE WORLD didn't know about it, doesn't mean some virus writer didn't; it just meant everyone continued to use un-patched Java installs in blissfull ignorance of the risk.
What the article says is that the same exploit (same hole in the Java Runtime Engine's security) allows access to multiple OSes (through multiple browsers)
So; johnny hacker writes his Java exploit; part of which decides what OS it is currently fiddling with, then has it deposit an appropriate payload for the OS.
What I took away from the article (C vs B) was that in the Bazaar everyone WAS free to do what the hell they wanted, but that a process of pseudo natural-selection would starve out weak/crap work; either through not ever being used, or through not getting developent time.
This would not particularly require a single decision making point (individual or comittee), just time and community consensus.
That aside, I don't think the Bazaar was ever meant to apply to the _kernel_ but to the Linux / other OSS system as a whole.
Filesystems would, to my mind be the ideal example:
Cathedral(Windows); which version of OUR proprietary FS would you like?
Bazaar (Linux); which of these basically unrelated systems would you like?
Obviously they would not REMAIN with the same value after you have offset them by DIFFERENT values. Once you CAST a void pointer and offset it (by the cast-to type's size) then unless they are cast to types that happen to have the same size then the resulting values will always be different.
Slashdot Mirror
Yes they were.
You decided to assume all my examples were trivial; they are not.
Way to miss the point; I was replying to the parent comment about "y'all have no right to expect a contract to be honoured".
... like yours.
My caveats were there specifically to assuage pedants from making assinine "but maybe they had KP on their student news site" comments
" When will people realize they don't have a "right" to be hosted?"
;)
If you have agreed a contract, abide by the T&Cs, and keep up payment; you have a RIGHT to be hosted, unless the contract is ended under its own T&Cs...
Except in the land of the "free" it appears
Oddly; enough that the idea seems like a good one!
"Changing product images is a reasonable thing to do - but all that needs is a change in the src of the "
And the VALUE to put in the SRC - which is what this would allow you to pull down as/if required.
"So now people can't bookmark specific products"
Fair comment, though I can think of places where similar features are desirable -> changing product images is a better usage.
"Useful from a commercial point of view. Really rather distracting from a visitor point of view. If I can't block it, I'm likely to find another vendor."
Good luck; sites designed to sell tend to ADVERTISE their wares. You seem to be thinking 3-second rotation; I'm thinking more 1-minute rotation of current "specials". Put bluntly; I have clients that will pay me to do this if its possible.
"This sounds practical, but at some stage you need to send the user to a new page anyway, and you can calculate new totals without having to make server calls."
1; I don't want the mechanism for calculations at the client side, so the calculation would require a reload, therefore this will make the page more responsive; i.e. better. The reason for non-client side? First: javascript is a shit language for anything other than DOM manipulation. Second: clients don't want their business logic exposed in javascript. Third: we don't want to download all the data required for those calculations to the client (prices in a code-manipulatable form should NEVER get to the client side, or be sent via post/get, prices just get displayed to the client, not manipulated by them)
Think about a checkout that calculates shipping costs globally; you need the location from the client. Depending on location the methods available for shipping will change. Depending on weight of goods (changes with quantity change) and location, the costs for each method change.
Thats a LOT of information to download to the client's machine to make the totals update without a server-call. Its also a ton of information (including prices) that I don't want the client side to have access to, and that I don't want javascript responsible for calculations on.
If I can pull down just the new value, rather than the whole page -> better!
"Ummm... why would you want an RSS new ticker on a webpage in the first place?"
Again; clients will pay for it. Just because YOU don't want it (or, in fact, that my client's clients don't want it), doesn't mean it has no value.
"Yes, lets just create something with no practical advantages over Flash/Iframe, but which requires a more recent browser to access."
There are plenty of advantages to not using flash. (reduce number of languages required to display 1 page and reduce number of external plugins required to display 1 page to name just 2 advantages)
Iframes are never a good idea.
And did you read the list of supported browsers? Only notable omission in the real world was safari...
2;
So...
repopulate your product page for a new product WITHOUT reloading the whole page.
Put a timer in, and have rotating feature products WITHOUT reloading the whole page on a timer.
Update your totals in your chckout / shopping cart WITHOUT reloading the whole page.
Write an RSS news ticker in html rather than flash...
Basically anything that you might have used flash or an IFrame for, you could do with this, javascript and a DIV tag... Pretty important news (if you write commercial websites)
Amiga OS had both those in 1985, IIRC.
True.
In fact, I think "class" would be the correct attribute. It defines a type for an element, which can be used by CSS, but is not necessarily limited to that. Elements can also have more than one class value (e.g. class='nofollow external_link' etc)
The fact that you don't necessarily use the nofollow class in your CSS is not a problem (and you can always style nofollow links differently should you wish...
To my mind it _might_ be a good thing if the rampant speed-advance slowed (a lot).
Consider:
We might get some return to efficient coding being the norm, instead of writing systems anyhow and throwing more/faster hardware at it until it runs acceptably (Microsoft; its you I'm looking at!)
Your (and your business') desktop machine might _not_ become obsolete in no more than 2 years, and mmight continue in useful service as something more sensible than a whole PC doing the job of a router...
Processor designers might spend more time (i know they already spend some) on innovating new ideas, rather than solving the problems with just ramping up clock speeds.
Cooling/Quietening technology might have a snowball's chance in hell of catching up with heat output?
(and the wild dreaming one)
Games writers might remember about gameplay, rather than better coloured lighting...
You fell into my cunning trap:
In time, certainly, good companies will come to measure success in terms of successful litigation.
We are in the here and now; and that is PATENTLY not what current legal departments are aiming at. They are very evidently "trigger happy" at the moment.
Costly losses, or embarrassing negative publicity from their over-eagerness is required to _sink in_ to upper management's minds before the goal will change.
Basically if SCO (etc) lose, badly, and either go bankrupt or see (the last few in SCO's case)investors vanish, other companies will begin to think a little more about firing off a law suit "because we can", or "because the other guy will probably cave".
How much have constant losses slowed the MPIAA/RIAA's flood of suits?
I'm in the "apple advocates" camp, sort of.
I think this reinforces two lessons of the early 21st century:
There is no such thing as a "nice" company.
There is no such thing as a responsible legal department.
(Companies, after all exsit to do _nothing_ but make money, legal departments can only demonstrate their performance in "amount of litigation participated in" - Its a brave new world, friends!)
Fair point.
Browsers get fed, essentially, random data from untrusted sources. To produce an inherently stable and secure browser, ALL data should be treated as broken and/or malicious until shown to be otherwise.
A key test would be; construct a large (2-3 Gigs) file full of mostly valid, but partially malformed / misaligned HTML/xhtml. Feed that to the browser.
It shouldn't crash, it _should_ gracefully decline to continue once it either runs low on resource, or gets stuck on nonsense markup. It should then release the resource, and you should be able to continue.
I doubt ANY current browser could pass that test.
And no, thats not a sensible real-world test. The best QA tests aren't; you test for the unreasonable to (to some degree) assure yourself the resonable will be OK. (I used to do QA, and that IS how you do it right...)
Better solution:
:(
Browser uses standard HTML/xhtml/xml format for its bookmarks.
Browser is capable of using this file from anywhere, including through http, or from a local file.
Bookmark management is still done through the browser interface, but the location of the bookmarks becomes browser independant.
For the http version, you would want a simple server side script to handle through http requests all the bookmark management (edit/add/delete/move around etc). There is no reason for this to be a complex script; you could put it on your own site, or have it on a central site, it should be your choice. You can even SSL and/or password protect your bookmarks, should you need to.
This simple system could even (gosh!) be cross browser and cross platform (its only an xml file, all it needs is a standard format, developed independant of each browser and then used by some or all)
This would give you bookmarks that could be accessed from multiple machines no problem.
For those who don't want http bookmarks, its just an xml file; put it on a floppy disk, USB flash drive or even your bluetooth mobile phone and take your bookmarks with you when you travel.
By default the browser just uses a local file in its app directory, so no visible change for those who _don't_ want common bookmarks.
All common sense.
All great for the end user.
Will never get implemented by ANY browser ever, I'll bet you
Get a modern decent browser; both Safari on my Mac, and Firefox on all of my PCs offer "Save this password: Yes? No? Never for this site?" or wording and options to that effect.
Upgrade or be damned!
Does it still count as news, to be told something that you KNEW was going to happen, has happened?
A large proportion of the BBC's and a fair proportion of Channel 4's current history educational programming is presented by real academics. Not necessarily "professors" (which is a specific academic-arena job, not entirely related to qualifications), but real academics.
Think of most of the history programs where you see the presenter, instead of hearing a narrator; plenty of those presenters have "proper" academic jobs. IIRC, even the "what the victorians did for us" guy, despite his silly costumes etc, is a pretty highly qualified man...
By my recollection, the "golden age" you referred to consisted mostly of leather-elbow-pad wearing crusties with a blackboard on the Open University. And they didn't represent any golden age of educational programming to my mind...
(educational programming, at its best, presents real and somewhat accurate information, but does so in an engaging manner; neither half of the package is optional)
How much better science is this than rubber tails for dolphins?!?
Sounds like good work to me.
"File managers do not have any higher access to the filesystem than the web browser already does."
Bullshit.
A browser has NO need to have rights to copy or delete files that it did not create. And it only need rights to create its own files in specific places.
By definition a File Manager needs to be able to copy and delete arbitrary files in the file system, otherwise you cannot Manage your Files with it.
There is no legitimate need for the two requirements to be brought together, and the fact that they end up co-existing in the same (externally scriptable, by definition as a web browser) leads to security risks.
" Lets make a deal: it is a bug in the security implementation of Java by Sun. Sheesh. That's what I said, didn't I?"
I think you read an implied slur into me simply having chosen to use the word "java" instead of "sun" when paraphrasing instead of actually quoting you. None was intended.
On to the point; as I recall the 2 main problems with ActiveX security are:
1; the browser (IE being _the_ ActiveX browser IIRC) pushes "security" options such as "allow signed scripts to run". Johnny Hacker is quite capable of signing his code, thus getting it run without question on most installs.
2; it is quite plausible to spoof your signature. Then even if you are requiring manual authentication of each signature before you let it run, it may well look to the casual user like a macromedia or Microsoft signature, and therefore it gets run.
Contrast with the (intention of the) Java security model, where it is not supposed to be possible to GET the kind of access that allows destruction / subversion in the first place.
Its the (piss-weak) "security" attitude that "if company X wants access that would let it format your drives, but only after scanning all the files on them, then its OK, because its company X, isn't it?" that is the problem with ActiveX.
No "program" run through your browser has legitimate need to that level of access to your local machine.
My personal opinion is that there are 2 fundamental flaws in how some companies view "browsers":
1 - they think that the web browser and the file manager shouyld become one.
2 - they think that goal justifies tying the browser tightly to the file system on the local machine, and justifies including low-level local access mechanisms into the browser and the things it can browse.
Personally I disagree; I think that having any "web format" of data/program able to escalate its rights to that kind of level is suicidal in terms of security, and therefore the risks of the required infrastructure make having your web browser serve to handle your local file system vastly outweight the minimal benefit of dropping one program from the machine.
I also think that may have been the longest sentence I've ever written; so I'll preserve it for posterity!
" There are differences. This is a bug in the security implementation of Sun. That's bad, since it goes for every platform."
What you should have really noted was that this is a bug in the security implementation of java. Which is bad.
ActiveX, on the other hand, doesn't HAVE a security implementation in which to get such a bug, which is terminally bad.
The "patch before admitting the problem" thing DOES happen on Windows.
But when it happens on windows it is microsoft "covering up their vulnerabilities".
Apparently, for you, when someone else does it they are doing something good...
Security by Obscurity, no matter who does it, it is still bad. Just because the WHOLE WORLD didn't know about it, doesn't mean some virus writer didn't; it just meant everyone continued to use un-patched Java installs in blissfull ignorance of the risk.
What the article says is that the same exploit (same hole in the Java Runtime Engine's security) allows access to multiple OSes (through multiple browsers)
:)
So; johnny hacker writes his Java exploit; part of which decides what OS it is currently fiddling with, then has it deposit an appropriate payload for the OS.
Voila; spreads through Windows and Linux.
Write once, run anywhere
What I took away from the article (C vs B) was that in the Bazaar everyone WAS free to do what the hell they wanted, but that a process of pseudo natural-selection would starve out weak/crap work; either through not ever being used, or through not getting developent time.
This would not particularly require a single decision making point (individual or comittee), just time and community consensus.
That aside, I don't think the Bazaar was ever meant to apply to the _kernel_ but to the Linux / other OSS system as a whole.
Filesystems would, to my mind be the ideal example:
Cathedral(Windows); which version of OUR proprietary FS would you like?
Bazaar (Linux); which of these basically unrelated systems would you like?
"then
(char*)p + 1 != (long*)p + 1"
Twat.
Obviously they would not REMAIN with the same value after you have offset them by DIFFERENT values.
Once you CAST a void pointer and offset it (by the cast-to type's size) then unless they are cast to types that happen to have the same size then the resulting values will always be different.
You cretin.