That's a good point. If they EOL Windows 98 before Longhorn is out, then a lot of people will switch to XP in the year before Longhorn arrives. This means that when Longhorn is released, the pressure to upgrade will have been significantly relieved. If they make the two dates relatively close together, a lot of people will simply go straight from 98 to Longhorn.
That KDE people are creating technologies to be able to make Gnome apps compatible with them is a sign of Gnome's success.
I don't see it that way. I use about 95% KDE applications on my desktop, and about 5% GTK/GNOME applications. The GTK/GNOME applications always bug me because of things like the file selector (which, for example, can't load files using the KDE IOSlaves).
Given that I find this kind of thing useful, and that I use 95% KDE applications, I can't agree that it's a sign of GNOME's success. It's just dragging the GTK/GNOME applications along where the original developers have failed to take them.
The remaining licence issues around Qt makes Gnome the obvious winner, as one cannot create commercial apps for Qt without paying fees.
That argument's been done to death. The basic points:
Commercial vendors have already overwhelmingly opted to use Qt instead of GTK.
Qt is a much nicer toolkit.
The fees are miniscule compared with the other costs involved in bringing a commercial product to market; it's more than made up by the increase in productivity.
The community were on Trolltech's back about making it GPL - they did so and now they are being criticised for listening.
The Linux desktop is ruled primarily by Free Software, not commercial applications.
That depends on what license you pick for Qt. Qt is available under a number of different licenses. For Free Software, you need to follow either the GPL or the QPL.
You can't really blame people for not getting into the semantic markup thing; until recently, the W3C itself was using table tags on their front page to do sidebars.
Unfortunately, that was due to the terrible state of browser support for CSS, something beyond the W3C's control. It's better that the W3C practice pragmatic web design that works, rather than idealistic web design that has problems communicating.
For that matter, they're now using CSS to do sidebars, which means that it takes two extra http requests to determine that certain parts are supposed to be floated
If you are referring to the fact that they use external stylesheets, that actually reduces the bandwidth usage/server load/download time. Sure, for the very first page view, it's an extra request, but in virtually all cases, it pays off to cache styling separate to documents, since:
Styles rarely change; content often does.
Styling can be shared between documents - no extra request/transmission time for stylesheets beyond the first pageview.
Since stylesheets shared between multiple documents are popular in terms of requests, they usually cache well.
there's no indication anywhere that the navigation links aren't part of the main content of the page.
They are in their own <div> element, with a heading and a "skip to next section" link. What else would you suggest?
How is this different to somebody hosting Windows ISOs? If there is software that is copyrighted by Tivo inside the images and they haven't given the people distributing them license to do so, then they are well within their rights to stop the distribution.
When it's something like file sharing, everybody's keen to jump on the "don't blame the technology" bandwagon. After all, file sharing can be used legitimately, right?
How is this any different? There are legitimate needs to send bulk mail aren't there? It's not only used by spammers is it?
The only difference I can see is that spam is something techies collectively hate, and copyright is something a lot of people are ambivelant about. Let's be fair and apply the same standards! Arguments don't stand or fall based upon whether we like the people involved.
The simple fact is, there is much more information in an XML file than is necessary to display the image. You can't deny that. And, therefore, it will be much larger, even if compressed.
The whole purpose of compression is to eliminate redundant information to get smaller file sizes. The more redundant information, the better the compression.
I believe that Konqueror DOES include application/xhtml+xml in its Accept header, but it processes the document using the HTML parser rather than a proper XML parser.
Close. It does process application/xhtml+xml documents as tag soup, but it doesn't advertise the fact. Please vote for bug #52665 to fix this.
I'm not convinced that web-developers need a knowledge of HTTP.
For hobby sites, no. For proper sites, definitely. Far too many people build a site without any understanding of how the browser talks to the server. Common mistakes include:
Thinking web statistics are reliable.
Wasting bandwidth by massive amounts
Slowing down sites by not being able to take advantage of HTTP pipelining, more efficient caching, etc.
Thinking the Referer and User-Agent headers are reliable.
Trusting request variables.
Serving different content to different clients without providing a Vary header (in other words, letting caches screw things up).
It's not a trivial topic that can be glossed over. You could literally waste gigabytes of bandwidth a month on a high profile site (or single slashdotting) if you don't pay attention to the interaction between server and client. While it's certainly possible to build a site without knowing the first thing about HTTP, it shouldn't be encouraged.
It's worrisome because suddenly a million script kiddies can now get this information as well, and will now have a better chance of choosing the correct point-and-click tool to exploit the identified box.
There have to be point-and-click tools to tell what a server is running anyway, it's not like it's the hardest thing in the world to do. Look:
Right-click on page.
Select 'View Page Info'.
Click the Headers tab.
Look at the response headers.
Dood! I just "hacked" Slashdot into telling me they are running Apache 1.3.26!
This isn't the breakthrough people think it is. It's just convenience for sysadmins who need to keep an eye on what versions they are running.
if you code XHTML, then all XHTML compliant browsers should render the same.
No they shouldn't. Differences in rendering are why you can surf the web on different size screens, with text-only interfaces, on PDAs, and so on. Do you really think that the Googlebot should render HTML documents in the same way as a normal browser? And the same as lynx? And the same as IBM Homepage Reader?
HTML encodes meaning. It's up to the user-agent to decide upon a method of presenting that information to the user.
if you code CSS, then all CSS compliant browsers should render the same.
Not according the the specification. There are plenty of areas that leave the final decision up to the user-agent, and that's not even taking into account variable pixel sizes, user stylesheets, relative units for lengths, and so on.
"Rendering the same" is impossible on the web. Even if you narrow it down to commonly used desktop configurations, what's a good rendering for somebody with a 21" monitor and perfect vision might not be good for somebody with a 15" monitor and poor vision. The Web is not paper, don't impose paper's limitations upon the web.
Isn't this what standards are all about?
Standards aid interoperability. They aren't magic - there's no way to ensure a decent layout without a lot of human effort on a case-by-case basis.
Yes, in case people aren't aware, KDE, like most projects that use the Qt toolkit, rely on a preprocessor to do a little of the work. Specifically, the C++ language is extended slightly to cover the concept of slots and signals, which is a very expressive way of coding up a GUI application.
...when it was also pointed out numerous times that SCO's unwillingness to divulge what is infringing and where [...] makes them ineligable for any compensatory or punitive damages of any kind.
I mentioned this briefly in the post you are replying to. You even quote it later on. Granted, I said "less likely" and not "impossible", but you agree that it's not impossible. How was I asleep?
Because only "weenies" make excuses for their vendor. I've only ever seen the excuse as a response to somebody complaining about Windows instability - whether it's Microsoft's fault or not is irrelevent if it's stopping you from getting your work done.
The same is true in Linux.
I dare say it is, but what does Linux have to do with it?
So they're saying that a poorly designed application can take down the entire operating system?
I suspect that they are referring to drivers and other kernel-space code. The standard Microsoft weenie excuse for instability in the past has been "it's the drivers!", blaming the video drivers is a favourite.
Remember that Microsoft don't write most Windows drivers, they don't have to because their market share is so great, any hardware manufacturer who doesn't supply Windows drivers is not competitive.
I believe this is the reason why Microsoft introduced their "Microsoft signed drivers" that are supposed to guarantee Microsoft-level stability (!).
However, I have to laugh at Microsoft when they claim 50% of crashes aren't their fault. It's like an advert for a diet pill saying "Doesn't cause death in over 90% of people!".
SCO would make a bad move to release the code before the trial under something less than a NDA.
Linux kernel developers would probably have the offending pieces rewritten in a week and back-ported to all 2.4/2.5 kernels within another week.
It's already been pointed out a hundred times, so once more won't hurt.
Rewriting Linux now will not do a damn bit of good. It doesn't absolve anyone from past infringements, and it won't mean that IBM did not breach their contract.
When it comes to trial, even if we all find out that Linux is infringing on SCO's IP, all the non-disclosure will have done is make the judge less likely to award damages to SCO.
The only reasonable explanation I have heard for the secrecy is that they can't substantiate any of their claims.
No. There is no difference. After all, they have and will keep what they already have. Nobody is taking it away.
A dependence on a particular software package is more than just a dependence on a particular set of bits. What if GCC/SCO UNIX users run into bugs? Are they going to employ programmers to trawl through the GCC updates to apply the fixes to the last release that worked on SCO UNIX? How long will that take? What happens from there? Will they have to maintain a separate tree?
These are expenses that can't be predicted or budgeted for well. A business could legitimately say that GCC is a risky affair - what operating system is next?
Every free project should immediately and without any exception drop all SCO support. This is a fight for life and death
No, it isn't. A struggle with an armed mugger is a fight for life or death, this is just software.
every move that makes the life of SCO users and customers miserable is a good one.
Are you serious? It's not like SCO UNIX users saw the news that SCO are suing everybody and decided to invest in that platform. There are SCO UNIX users that have been using it for years, and are dependent upon it. You can't just get rid of it overnight, even if you wanted to.
After all, they can and should jump ship as soon as possible.
According to you and me. But the difference between us is that I'm not saying that they should be made miserable until they use an operating system we like. That is just zealotry.
Dig around and you'll find RMS in the past saying essentially "Don't write software for the Mac because Apple is a bunch of litigious assholes" for more or less the same reasons that RMS is now saying essentially "Don't write software for SCO Unix because The SCO Group is a bunch of litigious assholes."
Surely you can appreciate the difference between not writing new software for a platform, and explicitly removing support for a platform from an established piece of software that many people are completely reliant upon?
The Free Software Movement might be about community, but Free Software, on its own, is just something that gets the job done for many people. If its developers yank your support because they don't like the operating system you use (why haven't they done this already for Windows?), then they run the risk of being percieved as unreliable. And how community-friendly is it to yank support for an OS that some people might be heavily reliant upon, when those people aren't responsible for the lawsuit madness?
The README suggests that removing support for SCO unix from GCC would hurt SCO's users, but not SCO. I disagree: If SCO's users can't develop software for their chosen platform anymore, then they will likely choose another platform, and SCO will be the one hurting in the end (which is the desired effect).
Well that depends on whether or not SCO's operating systems are a part of their business plan any more. A lot of people would argue that they are just a lawsuit company now.
There's a big problem with this proposed action though. What message does it send to people who happen to be using SCO, and decided upon Free Software (GCC) for their compiler? Essentially, they are getting the message "you are using an operating system we don't like, so we'll leave you high and dry". It's Free Software, so it's not as bad as when a proprietary vendor drops support, but it's still a big business risk.
We don't want to give the impression that you can't depend on Free Software unless you buy into the whole philosophy and only use FSF-approved operating systems. I think they have done the right thing by making a public issue out of this before actually doing anything, it lets people plan ahead in case this goes ahead, and it gives end-users a chance to talk to SCO about it (if they aren't already).
You said "immediately return to the last page you were on"
Do you see the difference there?
Look at it in context. There is no difference:
If they rank a page 1, and you click it, and immediately return to the search page
Step through it.
Search for something
Get results page
Click a link
Immediately return to the results page
If you immediately return from the page that google sent you to, then yes, it's going to be the last page you were on (assuming no author stupidity like redirects that break the back button).
And judging by zeitgeist IE still accounts for over 90% of their hits. I don't think anybody needs to worry about there being a skew from non-IE browser users.
Good point, any end-user feedback is going to skew in this way.
Slashdot Mirror
That's a good point. If they EOL Windows 98 before Longhorn is out, then a lot of people will switch to XP in the year before Longhorn arrives. This means that when Longhorn is released, the pressure to upgrade will have been significantly relieved. If they make the two dates relatively close together, a lot of people will simply go straight from 98 to Longhorn.
I don't see it that way. I use about 95% KDE applications on my desktop, and about 5% GTK/GNOME applications. The GTK/GNOME applications always bug me because of things like the file selector (which, for example, can't load files using the KDE IOSlaves).
Given that I find this kind of thing useful, and that I use 95% KDE applications, I can't agree that it's a sign of GNOME's success. It's just dragging the GTK/GNOME applications along where the original developers have failed to take them.
That argument's been done to death. The basic points:
That depends on what license you pick for Qt. Qt is available under a number of different licenses. For Free Software, you need to follow either the GPL or the QPL.
Unfortunately, that was due to the terrible state of browser support for CSS, something beyond the W3C's control. It's better that the W3C practice pragmatic web design that works, rather than idealistic web design that has problems communicating.
If you are referring to the fact that they use external stylesheets, that actually reduces the bandwidth usage/server load/download time. Sure, for the very first page view, it's an extra request, but in virtually all cases, it pays off to cache styling separate to documents, since:
They are in their own <div> element, with a heading and a "skip to next section" link. What else would you suggest?
I'm not getting the overlap here with 3.1.94, perhaps nitehorse is using an older beta.
On the other hand, Firebird 0.7 has a weird "jumping margin" bug that increases the top margin of the floatbox when you hover over one of the links.
Not really. It's trivial to set up a private NNTP server. Okay, you can't call private NNTP servers "Usenet", but it's the exact same software.
How is this different to somebody hosting Windows ISOs? If there is software that is copyrighted by Tivo inside the images and they haven't given the people distributing them license to do so, then they are well within their rights to stop the distribution.
When it's something like file sharing, everybody's keen to jump on the "don't blame the technology" bandwagon. After all, file sharing can be used legitimately, right?
How is this any different? There are legitimate needs to send bulk mail aren't there? It's not only used by spammers is it?
The only difference I can see is that spam is something techies collectively hate, and copyright is something a lot of people are ambivelant about. Let's be fair and apply the same standards! Arguments don't stand or fall based upon whether we like the people involved.
The whole purpose of compression is to eliminate redundant information to get smaller file sizes. The more redundant information, the better the compression.
Close. It does process application/xhtml+xml documents as tag soup, but it doesn't advertise the fact. Please vote for bug #52665 to fix this.
For hobby sites, no. For proper sites, definitely. Far too many people build a site without any understanding of how the browser talks to the server. Common mistakes include:
It's not a trivial topic that can be glossed over. You could literally waste gigabytes of bandwidth a month on a high profile site (or single slashdotting) if you don't pay attention to the interaction between server and client. While it's certainly possible to build a site without knowing the first thing about HTTP, it shouldn't be encouraged.
There have to be point-and-click tools to tell what a server is running anyway, it's not like it's the hardest thing in the world to do. Look:
Dood! I just "hacked" Slashdot into telling me they are running Apache 1.3.26!
This isn't the breakthrough people think it is. It's just convenience for sysadmins who need to keep an eye on what versions they are running.
No they shouldn't. Differences in rendering are why you can surf the web on different size screens, with text-only interfaces, on PDAs, and so on. Do you really think that the Googlebot should render HTML documents in the same way as a normal browser? And the same as lynx? And the same as IBM Homepage Reader?
HTML encodes meaning. It's up to the user-agent to decide upon a method of presenting that information to the user.
Not according the the specification. There are plenty of areas that leave the final decision up to the user-agent, and that's not even taking into account variable pixel sizes, user stylesheets, relative units for lengths, and so on.
"Rendering the same" is impossible on the web. Even if you narrow it down to commonly used desktop configurations, what's a good rendering for somebody with a 21" monitor and perfect vision might not be good for somebody with a 15" monitor and poor vision. The Web is not paper, don't impose paper's limitations upon the web.
Standards aid interoperability. They aren't magic - there's no way to ensure a decent layout without a lot of human effort on a case-by-case basis.
KDE is in Fink.
Yes, in case people aren't aware, KDE, like most projects that use the Qt toolkit, rely on a preprocessor to do a little of the work. Specifically, the C++ language is extended slightly to cover the concept of slots and signals, which is a very expressive way of coding up a GUI application.
The ones they use at the Library of Congress of course!
I mentioned this briefly in the post you are replying to. You even quote it later on. Granted, I said "less likely" and not "impossible", but you agree that it's not impossible. How was I asleep?
Because only "weenies" make excuses for their vendor. I've only ever seen the excuse as a response to somebody complaining about Windows instability - whether it's Microsoft's fault or not is irrelevent if it's stopping you from getting your work done.
I dare say it is, but what does Linux have to do with it?
I suspect that they are referring to drivers and other kernel-space code. The standard Microsoft weenie excuse for instability in the past has been "it's the drivers!", blaming the video drivers is a favourite.
Remember that Microsoft don't write most Windows drivers, they don't have to because their market share is so great, any hardware manufacturer who doesn't supply Windows drivers is not competitive.
I believe this is the reason why Microsoft introduced their "Microsoft signed drivers" that are supposed to guarantee Microsoft-level stability (!).
However, I have to laugh at Microsoft when they claim 50% of crashes aren't their fault. It's like an advert for a diet pill saying "Doesn't cause death in over 90% of people!".
It's already been pointed out a hundred times, so once more won't hurt.
Rewriting Linux now will not do a damn bit of good. It doesn't absolve anyone from past infringements, and it won't mean that IBM did not breach their contract.
When it comes to trial, even if we all find out that Linux is infringing on SCO's IP, all the non-disclosure will have done is make the judge less likely to award damages to SCO.
The only reasonable explanation I have heard for the secrecy is that they can't substantiate any of their claims.
A dependence on a particular software package is more than just a dependence on a particular set of bits. What if GCC/SCO UNIX users run into bugs? Are they going to employ programmers to trawl through the GCC updates to apply the fixes to the last release that worked on SCO UNIX? How long will that take? What happens from there? Will they have to maintain a separate tree?
These are expenses that can't be predicted or budgeted for well. A business could legitimately say that GCC is a risky affair - what operating system is next?
No, it isn't. A struggle with an armed mugger is a fight for life or death, this is just software.
Are you serious? It's not like SCO UNIX users saw the news that SCO are suing everybody and decided to invest in that platform. There are SCO UNIX users that have been using it for years, and are dependent upon it. You can't just get rid of it overnight, even if you wanted to.
According to you and me. But the difference between us is that I'm not saying that they should be made miserable until they use an operating system we like. That is just zealotry.
Surely you can appreciate the difference between not writing new software for a platform, and explicitly removing support for a platform from an established piece of software that many people are completely reliant upon?
The Free Software Movement might be about community, but Free Software, on its own, is just something that gets the job done for many people. If its developers yank your support because they don't like the operating system you use (why haven't they done this already for Windows?), then they run the risk of being percieved as unreliable. And how community-friendly is it to yank support for an OS that some people might be heavily reliant upon, when those people aren't responsible for the lawsuit madness?
Well that depends on whether or not SCO's operating systems are a part of their business plan any more. A lot of people would argue that they are just a lawsuit company now.
There's a big problem with this proposed action though. What message does it send to people who happen to be using SCO, and decided upon Free Software (GCC) for their compiler? Essentially, they are getting the message "you are using an operating system we don't like, so we'll leave you high and dry". It's Free Software, so it's not as bad as when a proprietary vendor drops support, but it's still a big business risk.
We don't want to give the impression that you can't depend on Free Software unless you buy into the whole philosophy and only use FSF-approved operating systems. I think they have done the right thing by making a public issue out of this before actually doing anything, it lets people plan ahead in case this goes ahead, and it gives end-users a chance to talk to SCO about it (if they aren't already).
Look at it in context. There is no difference:
Step through it.
If you immediately return from the page that google sent you to, then yes, it's going to be the last page you were on (assuming no author stupidity like redirects that break the back button).
Good point, any end-user feedback is going to skew in this way.