It's not about how long it will take them to run out of money, it's whether it's more profitable to pay the fine or continue to break the law.
I assure you, Microsoft shareholders won't be saying "it's okay, we can last for years like this" to the Board of Directors, they'll be saying "why are we paying a billion dollars per year fine?"
If that were the case, they'd be making it as difficult as possible for Microsoft to comply with their demands instead of telling them exactly what they are doing wrong and giving them years to correct their mistake.
I know it's trendy to accuse the EU of being greedy and anti-American, and I don't deny that the money will be happily spent, but that doesn't mean Microsoft isn't breaking the law and it doesn't mean the EU aren't right to fine them.
Microsoft could easily avoid these fines by complying with the court ruling. They have chosen to make every effort to avoid doing so, and these fines are the result.
It seems to me that you've started with your conclusion - that ReiserFS is not innovative - and used that to draw the conclusion that it must therefore suffer from the same problems as other filesystems. This is backwards logic. Please reverse your logic - look at its actual features and use that to decide whether or not it is innovative.
In particular, you seem focus on the need for application support. The whole philosophy behind ReiserFS is that separate namespaces for files and metadata is a bad idea, and that metadata should be exposed in the existing namespace - as files and directories.
The consequence of this is that applications don't need special support for ReiserFS's metadata. If, for example, you wrote an MP3 plugin that exposed the ID3 metadata, you would be able to search this with grep and locate, and edit it with vi and EMACS, without any changes whatsoever to grep, locate, vi or EMACS. Since the filesystem is exposing this metadata as files and directories, anything that supports files and directories will be able to access the metadata.
So the problem of metadata might mean that other filesystems require special application support, but it's precisely because ReiserFS is innovative that this isn't a problem for it. Which other filesystems are tackling metadata in this way? Are there any?
That's a bit of a trick question. For example, no applications specifically "leverage" (What's with the PHB-speak? "Use" is far more natural than "leverage".) ZFS' self-healing features, but that doesn't mean they aren't useful. Here's some features of ZFS.
Nope. If you want things doing with ReiserFS, you can contract Namesys, and commercial support for ZFS is included in Solaris contracts. These are hardly lone hackers with only CVS available, there are businesses behind them.
a. WinFS had difficulty functioning over a network
b. Microsoft's target customer is business
c. Businesses use networks
Therefore, WinFS would not be suited for business usage, making it unimportant.
You misspelt making it a really bad design decision.
Hey, if everyone wants to bag on Microsoft not making a next generation file system, what is stopping Linux and the Open Source community from doing it?
The open-source community does have innovation in their filesystems. Take a look at ReiserFS or ZFS for example.
If they didn't put back WinFS, they couldn't use it as vapo^W a feature of their next product. And when that product comes out, they'll push it back to the product after that, just like they've been doing for the past seven or eight years or so.
WinFS is the perpetual motion machine of vapourware. They are constantly promising it for their next product, but they never seem to deliver. That doesn't stop $NEXT_PRODUCT from being compared favourably with the competition because of WinFS by PHBs though.
Why didn't you use the ImageMagick extension in PECL? There's plenty of image processing options with PHP, just because MagickWand didn't work out for you, that doesn't mean you have to concoct a monstrous hybrid of PHPerl.
Er, you don't have to parse it. Every browser that supports XMLHttpRequest parses the XML automatically with native code, you don't have to do a thing.
Isn't one of the talking points of CSS that we get away from using tables for layout?
You are confusing two different types of table. The HTML <table> element describes a relationship across multiple axes. The CSS display: table-* property values describe a grid-like layout scheme.
These are totally different things at totally different conceptual levels. There are only two things that link them - the word "table" and the fact that the usual method of presenting information that is related across two axes is in a grid.
Please do not confuse HTML tables with CSS tables. They are totally different things, and the arguments against "table layouts" are specifically targeted at HTML tables and not CSS tables.
All ACID2 test for is proper handling of improper or edgy code... It doesn't show what good code written to spec is supposed to look like.
Please do not spread this myth. It is simply not true. If you had actually read the Acid2 technical guide instead of relying on Slashdot hearsay, you would know this. From a previous comment of mine:
Have you actually bothered to read the Acid2 page? Because I hear this repeated all the time, and it's downright misleading.
There is a checklist of about a dozen things the Acid2 page tests. Incorrect code is just one of them. It is necessary to include incorrect code in a test like this. How else are you going to check whether a browser follows the CSS error handling rules?
It's incorrect code, sure, but it's incorrect code that has a defined rendering according to the CSS specifications. It's not something a compliant browser would trip up on. There is a correct way to parse the incorrect code, and the Acid2 page tests to see if a browser parses it correctly - among many other things it tests for.
Where are you guys getting this idea that the Acid2 test is all about error handling? It's a very small part of the test, but plenty of Slashdotters seem convinced that the test revolves around broken code and nothing else. Was there a weekly meeting I missed wher eyou all got this myth drilled into your heads?
Fonts on the web should adhere to a couple of design principles that make them more easier to read, such as using a high x-height
This is precisely the thing that makes Verdana such a lousy font for the web.
Don't get me wrong, I totally understand what you are saying about the x-height and how it makes text more readable, but the thing about the web is that you can't know that the reader is actually using that font. Sure, you can suggest Verdana, but if they don't have it on their system, or they prefer another font, the x-height you assume to be in use usually ends up being much smaller. This means that what is a perfectly readable font size for you, using Verdana, may end up being totally unreadable for somebody else, because even if the same font size is in use, the lowercase letters all appear much smaller.
Verdana is a nice font. I actually have it as my browser default. But when it comes to web designers specifying Verdana, it causes more trouble than it's worth. Maybe if they learnt to stay away from messing with the font size it would be okay, but there are precious few web designers who do that.
And yes, they probably could spend a bit of time and get aliases working nicely with @import etc. But that would raise the complexity of implementations for very little gain. I'm sure that if every other thing about CSS was perfect, they'd get around to aliases, but at the moment, there's much more important things for them to be working on, both the W3C that are writing the specs and the browser developers who are implementing them.
The default font size is fine. It's Slashdot's new style that did this. If it used the default font size, you'd be able to read it. Slashdot's stylesheets make <pre> elements 93% smaller than the parent element font size. And the parent element font size is already 82% smaller than your default font size. This means Slashdot's stylesheet is essentially saying: "You know that font size you have configured to be readable in your browser? Well I think this text should be 25% smaller than that."
what user is worth keeping who isn't "computer-savvy" enough to understand what a Junk Mail folder is?
The kind of user that pays you money? And there are a lot of people that don't understand spam filtering. Unlike most other email concepts, this one doesn't really have a snail-mail analogue.
send them all Gmail invites
I already do this. Without fail, every single Hotmail user that I have sent an invite to has either signed up and not switched, or not bothered signing up at all. Hotmail users are happy with crap. Think about it - if they weren't, they wouldn't be with Hotmail in the first place, would they?
The argument is that XSS vulnerabilities are not a mark of bad or insecure code but rather a nasty but unavoidable risk that's a part of JavaScript
Er, no. XSS attacks are caused by sloppy web application developers that fail to encode user-supplied data for output in the appropriate way, and by sloppy web developers that trust that whatever was submitted by a user was submitted by the user intentionally.
Both of these factors have technical solutions that are 100% effective and have been well-known for years. The former has nothing specifically to do with JavaScript anyway, it's just that the holes are most often used to sneak JavaScript onto a page.
This article is a total crock of shit. For instance when it says:
It is of the utmost importance to note that a page that has an "XSS vulnerablity" is no more dangerous than visiting a random result generated by a Google search
It's no more dangerous in terms of security for the client machine. If Hotmail has a security hole, it doesn't make it more likely that somebody will get onto your computer. But they can still read and delete your email, and send email from your account.
Actually, I take that back, it is more dangerous in terms of security for the client machine. With tools like the NoScript Firefox extension, and the similar mechanisms other browsers have, many people disable JavaScript for the random websites found with Google, but enable them for websites they trust, like Hotmail. So if Hotmail has an XSS vulnerability, they will be executing malicious JavaScript even though they only intended to allow trusted JavaScript to be executed.
This author seems to have no real clue about web security. I guess this is why Slashdot shouldn't link to random weblog entries.
Grab something like SpamAssassin, and set it up to add headers telling you what rules have been triggered. Then send an email from your web application to that account, and examine the headers. While Hotmail probably don't use the exact same rules as SpamAssassin, it's an easy way to spot obvious stuff for you to fix. For example, using too much HTML, particular phrases, too many capital letters, being on blacklists, etc, can all be remedied by you without Microsoft's involvement.
I also seem to remember that Hotmail strongly discriminates against senders who don't have SPF set up, so it's probably a good idea to enable that for your domain.
in general I would think it would be to the publishers' benefit to direct people to their website proper for the full text.
But if you read the whole thread, you'll see I'm specifically taking issue with the claim that the readers are complaining about this. You said that, as a reader, you prefer not to have full-text feeds too.
If they're selling stuff, that's where it will be.
If the reader wants to buy stuff, they'll click through anyway.
If they're getting ad revenue, that's where they will be.
You can include ads in feeds.
What benefit is there (for publishers) to giving away content "for free" in the RSS feed?
Well that depends on why the publisher is publishing, but in general it's about reaching more people.
Most publishers don't publish the thing of value, most publishers publish as a form of marketing. If I read that an online shop I buy from has a new product in stock, it doesn't matter if I read it through a feed or on the website, what matters is that I read it at all. And I'm far more likely to subscribe to a full-text feed. What I am reading is not the thing of value, the fact that I am reading it is the thing of value. Full-text feeds increase the value to many publishers in this way.
Even when the thing of value is the thing being published, it may still make sense to have full-text feeds. For instance, if webloggers are more likely to subscribe to full-text feeds, then an online news source will get more inbound links by publishing full-text feeds. The people following those links might never have even heard of the website if they hadn't followed the links. The people reading feeds aren't the only people you can reach through feeds.
I want informative titles, so I can see almost all my daily feeds at a glance. If the title grabs me, I'll expand it to read the summary. If the summary is good, I'll go to the article. Full-text feeds aren't as bad for this if they are well written articles, where the first paragraph is itself a good summary, but often they are not.
Well that's an argument for not having badly written articles, not an argument for not having full-text feeds. And the vast majority of partial feeds I've seen are either a bare link or the "summary" is just the first sentence or paragraph from the article anyway. I think that the number of feeds with an actual summary in them is negligable.
And again, even if 95% of the readers wanted partial feeds, that isn't an argument against full-text feeds. There's nothing stopping publishers from offering both.
Now OTOH, I'd be very interested in a reader that let displayed a list of (informative) titles, showed a (good) summary when clicked, and then let me (optionally) expand it into the full article view. If readers supported this, and all feeds were coded that way, I'd be completely on board with full text feeds.
That sounds like a good idea.
You probably have broadband, right? So why even care about having to fetch the full version?
Because:
That would involve starting a web browser
That would involve me wading through loads of extraneous junk
The last point is especially important. The state of web design at the moment is awful. It seems like most pages are focused on everything but the article. It's so much quicker and easier to read a feed as dark text on a light background in a reasonable font size, without five different navigation bars, without a list of other articles (that already appeared in the feed so I don't need to be told again), without a huge space down one side cased by fixed-width design, etc.
I want RSS to be a notifier with "teasers"...if I wanted to suck all that bandwidth for full text, I'd just open Opera with a saved tab-set and go directly to the web sites.
Most people don't have the bandwidth they use to download as an important motivator. Why do you? Are you reading feeds with your mobile phone or something?
I want Atom/RSS feeds to be full-text because then it gives me the choice of reading it in my aggregator or reading it on the original website. It's usually more convenient to read it in my aggregator.
In any case, your motivations are unimportant, because there's nothing stopping publishers from offering full-text feeds and partial feeds for readers like you who are worried about the bandwidth they are using to download.
Yes, but it doesn't do that because it's valid, it does it for some other reason, like not supporting that specific property. You can test this by finding valid code that Internet Explorer chokes on, and adding a superfluous character at the bottom of the stylesheet, making it invalid. Internet Explorer will still choke. Validity isn't what causes Internet Explorer to choke, so there's no harm in writing valid code.
Slashdot Mirror
It's not about how long it will take them to run out of money, it's whether it's more profitable to pay the fine or continue to break the law.
I assure you, Microsoft shareholders won't be saying "it's okay, we can last for years like this" to the Board of Directors, they'll be saying "why are we paying a billion dollars per year fine?"
If that were the case, they'd be making it as difficult as possible for Microsoft to comply with their demands instead of telling them exactly what they are doing wrong and giving them years to correct their mistake.
I know it's trendy to accuse the EU of being greedy and anti-American, and I don't deny that the money will be happily spent, but that doesn't mean Microsoft isn't breaking the law and it doesn't mean the EU aren't right to fine them.
Microsoft could easily avoid these fines by complying with the court ruling. They have chosen to make every effort to avoid doing so, and these fines are the result.
It seems to me that you've started with your conclusion - that ReiserFS is not innovative - and used that to draw the conclusion that it must therefore suffer from the same problems as other filesystems. This is backwards logic. Please reverse your logic - look at its actual features and use that to decide whether or not it is innovative.
In particular, you seem focus on the need for application support. The whole philosophy behind ReiserFS is that separate namespaces for files and metadata is a bad idea, and that metadata should be exposed in the existing namespace - as files and directories.
The consequence of this is that applications don't need special support for ReiserFS's metadata. If, for example, you wrote an MP3 plugin that exposed the ID3 metadata, you would be able to search this with grep and locate, and edit it with vi and EMACS, without any changes whatsoever to grep, locate, vi or EMACS. Since the filesystem is exposing this metadata as files and directories, anything that supports files and directories will be able to access the metadata.
So the problem of metadata might mean that other filesystems require special application support, but it's precisely because ReiserFS is innovative that this isn't a problem for it. Which other filesystems are tackling metadata in this way? Are there any?
Somebody is attempting to use this type of publicity to get David Hasselhoff to #1 in the UK music charts.
That's a bit of a trick question. For example, no applications specifically "leverage" (What's with the PHB-speak? "Use" is far more natural than "leverage".) ZFS' self-healing features, but that doesn't mean they aren't useful. Here's some features of ZFS.
Nope. If you want things doing with ReiserFS, you can contract Namesys, and commercial support for ZFS is included in Solaris contracts. These are hardly lone hackers with only CVS available, there are businesses behind them.
You misspelt making it a really bad design decision.
The open-source community does have innovation in their filesystems. Take a look at ReiserFS or ZFS for example.
On the contrary, plenty of corporations might lie, but how many companies can get away with telling the same lie over and over and over again?
"Yeah, sure, WinFS will be in this one. It's not like last time, or the time before that, or the time before that. We mean it this time."
If they didn't put back WinFS, they couldn't use it as vapo^W a feature of their next product. And when that product comes out, they'll push it back to the product after that, just like they've been doing for the past seven or eight years or so.
WinFS is the perpetual motion machine of vapourware. They are constantly promising it for their next product, but they never seem to deliver. That doesn't stop $NEXT_PRODUCT from being compared favourably with the competition because of WinFS by PHBs though.
Not only does Internet Explorer not support it, as far as I know, nobody has ever implemented it. That's why font-size-adjust is no longer part of CSS 2.1.
Why didn't you use the ImageMagick extension in PECL? There's plenty of image processing options with PHP, just because MagickWand didn't work out for you, that doesn't mean you have to concoct a monstrous hybrid of PHPerl.
Er, you don't have to parse it. Every browser that supports XMLHttpRequest parses the XML automatically with native code, you don't have to do a thing.
You are confusing two different types of table. The HTML <table> element describes a relationship across multiple axes. The CSS display: table-* property values describe a grid-like layout scheme.
These are totally different things at totally different conceptual levels. There are only two things that link them - the word "table" and the fact that the usual method of presenting information that is related across two axes is in a grid.
Please do not confuse HTML tables with CSS tables. They are totally different things, and the arguments against "table layouts" are specifically targeted at HTML tables and not CSS tables.
Please do not spread this myth. It is simply not true. If you had actually read the Acid2 technical guide instead of relying on Slashdot hearsay, you would know this. From a previous comment of mine:
Yes, which is why downloadable fonts were added to CSS in 1998. But nobody bothered implementing it, so it was taken out again.
This is precisely the thing that makes Verdana such a lousy font for the web.
Don't get me wrong, I totally understand what you are saying about the x-height and how it makes text more readable, but the thing about the web is that you can't know that the reader is actually using that font. Sure, you can suggest Verdana, but if they don't have it on their system, or they prefer another font, the x-height you assume to be in use usually ends up being much smaller. This means that what is a perfectly readable font size for you, using Verdana, may end up being totally unreadable for somebody else, because even if the same font size is in use, the lowercase letters all appear much smaller.
Verdana is a nice font. I actually have it as my browser default. But when it comes to web designers specifying Verdana, it causes more trouble than it's worth. Maybe if they learnt to stay away from messing with the font size it would be okay, but there are precious few web designers who do that.
No, I think it means most people realised through practical experience with CSS 1 that such things really weren't as necessary as you first imagine.
@import has always been part of CSS, right from CSS 1. He was saying that things like @import make aliases more complex than you first think.
And yes, they probably could spend a bit of time and get aliases working nicely with @import etc. But that would raise the complexity of implementations for very little gain. I'm sure that if every other thing about CSS was perfect, they'd get around to aliases, but at the moment, there's much more important things for them to be working on, both the W3C that are writing the specs and the browser developers who are implementing them.
The default font size is fine. It's Slashdot's new style that did this. If it used the default font size, you'd be able to read it. Slashdot's stylesheets make <pre> elements 93% smaller than the parent element font size. And the parent element font size is already 82% smaller than your default font size. This means Slashdot's stylesheet is essentially saying: "You know that font size you have configured to be readable in your browser? Well I think this text should be 25% smaller than that."
The kind of user that pays you money? And there are a lot of people that don't understand spam filtering. Unlike most other email concepts, this one doesn't really have a snail-mail analogue.
I already do this. Without fail, every single Hotmail user that I have sent an invite to has either signed up and not switched, or not bothered signing up at all. Hotmail users are happy with crap. Think about it - if they weren't, they wouldn't be with Hotmail in the first place, would they?
Er, no. XSS attacks are caused by sloppy web application developers that fail to encode user-supplied data for output in the appropriate way, and by sloppy web developers that trust that whatever was submitted by a user was submitted by the user intentionally.
Both of these factors have technical solutions that are 100% effective and have been well-known for years. The former has nothing specifically to do with JavaScript anyway, it's just that the holes are most often used to sneak JavaScript onto a page.
This article is a total crock of shit. For instance when it says:
It's no more dangerous in terms of security for the client machine. If Hotmail has a security hole, it doesn't make it more likely that somebody will get onto your computer. But they can still read and delete your email, and send email from your account.
Actually, I take that back, it is more dangerous in terms of security for the client machine. With tools like the NoScript Firefox extension, and the similar mechanisms other browsers have, many people disable JavaScript for the random websites found with Google, but enable them for websites they trust, like Hotmail. So if Hotmail has an XSS vulnerability, they will be executing malicious JavaScript even though they only intended to allow trusted JavaScript to be executed.
This author seems to have no real clue about web security. I guess this is why Slashdot shouldn't link to random weblog entries.
Grab something like SpamAssassin, and set it up to add headers telling you what rules have been triggered. Then send an email from your web application to that account, and examine the headers. While Hotmail probably don't use the exact same rules as SpamAssassin, it's an easy way to spot obvious stuff for you to fix. For example, using too much HTML, particular phrases, too many capital letters, being on blacklists, etc, can all be remedied by you without Microsoft's involvement.
I also seem to remember that Hotmail strongly discriminates against senders who don't have SPF set up, so it's probably a good idea to enable that for your domain.
But if you read the whole thread, you'll see I'm specifically taking issue with the claim that the readers are complaining about this. You said that, as a reader, you prefer not to have full-text feeds too.
If the reader wants to buy stuff, they'll click through anyway.
You can include ads in feeds.
Well that depends on why the publisher is publishing, but in general it's about reaching more people.
Most publishers don't publish the thing of value, most publishers publish as a form of marketing. If I read that an online shop I buy from has a new product in stock, it doesn't matter if I read it through a feed or on the website, what matters is that I read it at all. And I'm far more likely to subscribe to a full-text feed. What I am reading is not the thing of value, the fact that I am reading it is the thing of value. Full-text feeds increase the value to many publishers in this way.
Even when the thing of value is the thing being published, it may still make sense to have full-text feeds. For instance, if webloggers are more likely to subscribe to full-text feeds, then an online news source will get more inbound links by publishing full-text feeds. The people following those links might never have even heard of the website if they hadn't followed the links. The people reading feeds aren't the only people you can reach through feeds.
Well that's an argument for not having badly written articles, not an argument for not having full-text feeds. And the vast majority of partial feeds I've seen are either a bare link or the "summary" is just the first sentence or paragraph from the article anyway. I think that the number of feeds with an actual summary in them is negligable.
And again, even if 95% of the readers wanted partial feeds, that isn't an argument against full-text feeds. There's nothing stopping publishers from offering both.
That sounds like a good idea.
Because:
The last point is especially important. The state of web design at the moment is awful. It seems like most pages are focused on everything but the article. It's so much quicker and easier to read a feed as dark text on a light background in a reasonable font size, without five different navigation bars, without a list of other articles (that already appeared in the feed so I don't need to be told again), without a huge space down one side cased by fixed-width design, etc.
I don'
When Robert Scoble started writing about this and saying that he simply wouldn't subscribe to partial feeds, there were plenty of people agreeing with him.
Most people don't have the bandwidth they use to download as an important motivator. Why do you? Are you reading feeds with your mobile phone or something?
I want Atom/RSS feeds to be full-text because then it gives me the choice of reading it in my aggregator or reading it on the original website. It's usually more convenient to read it in my aggregator.
In any case, your motivations are unimportant, because there's nothing stopping publishers from offering full-text feeds and partial feeds for readers like you who are worried about the bandwidth they are using to download.
Yes, but it doesn't do that because it's valid, it does it for some other reason, like not supporting that specific property. You can test this by finding valid code that Internet Explorer chokes on, and adding a superfluous character at the bottom of the stylesheet, making it invalid. Internet Explorer will still choke. Validity isn't what causes Internet Explorer to choke, so there's no harm in writing valid code.
Sure. Just build massive electric fans to blow the pollution away and invite the hungry people over for dinner.