[Y]es, [cleaning out markup cruft] can make a pretty big difference with uncompressed html, it makes little difference when gzip gets back in the game.
True, but I don't understand why you continue to set up a comparison between the markup with which a document is fashioned and the method by which it is delivered. Both offer savings. Your original example was what you did when you couldn't compress the data and how that somehow disproves the argument that markup reconsideration offers no benefit to those implementing Web sites.
In setting up a comparison between delivery and design, you stray from your original point, obscuring the thread of reasoning to which most seem to be responding here.
Another tidbit for your consideration: Although the data may be compressed on transfer, it usually is not stored in a compressed format within clients' caches. There are even a lot of clients in use that don't accept compressed data feeds. And there are a lot that neither accept, nor store, compressed data. One particularly relevant example set would be all those lightweight Windows CE devices that have been on the market for years. Speaking from experience, my incredibly useful Aero 8000 doesn't benefit much from data compression, and given that its memory is only 64 MB for OS + apps + data, I (as a user) don't appreciate cloggy Web documents. I guess that's the risk we all run when visiting sites we didn't build ourselves, eh?:)
But if you look at other posts around this thread, that accounts for less than a buck a year.
... for you. Look elsewhere for why you need to qualify that statement a bit more strongly and a few reasons you might want to consider before bandying it about so.
I'm the only one on the design team that works almost exclusively in CSS. The current design on the site wasn't made by me, the old one wasn't either.
Then I would suggest that it was a pretty poor example to use, or rely upon, to demonstrate a real-world challenge to Zeldman's case.
You can get a better idea of my CSS style by going to a css layout version of our current design or my not close to being done SVG site. Which has a very clean body.
It's unfortunate that the layout version isn't close to valid HTML or that the CSS isn't much better. The markup for the SVG site is a bit better, though the validator doesn't catch the odd inclusion of XHTML style BR elements in a document clearly marked as HTML 4.01 Transitional. I'll leave a check of its CSS to you, I'm getting timeouts on multiple requests to your server. You may want to investigate its cache status, too. But I assume both are incomplete projects, and everyone makes mistakes (though why they would post them to/. is beyond me).
The change was to pretty basic CSS and worked fine in all browsers. Although it still wasn't *exactly* what the old version looked like (text a couple points off here and there).
I suspect that the search for pixel- and proportion-perfect design is a root issue. Thinking in those terms when implementing on the Web is troubling and could even be labeled by some as naive or impossible beyond the narrowest of visitor communities. I begin to understand the excessive use of DIV elements in your markup.
[A]s I pointed out 3-4% is only 40megs. We pay $10 for 10 gigs of transfer and the account on the machine. So 40 megs is less than 5 cents. Hardly anything compared to the 400% difference of having gzip turned off.
Bandwidth is a resource, and like any resouce, it
ought to be conserved where possible. Read my original post where I anticipate (and do not contest) a return to the issue of transfer compression. You don't have sufficient traffic to worry about cutting even small chunks from your costs, fine. Don't indict the practice for everyone else then ("I can assure you [bandwidth savings] are negligible.") or just send me the five cents you will sav every day, I'll put it to good use.:p
The point is this: you still seem to be glossing over my earlier observation that your ~4% savings could have been even greater had you actually understood the holistic approach Zeldman offers. It troubles me to think that you still don't "get it", even though you offer a couple new example sites that would seem to suggest that you do, in part.
If I were on dial-up (which thankfully, I'm not at the moment), I would certainly be appreciative as a user for the additional savings in time and bytes. Yes, there are still people on metered plans out there in the world. How much bandwidth a document or a site needs is not only a cost for the supplier, but also for the consumer, in money and time.
No one is contesting the utility of transfer compression. Stop complaining about the lack of gzip encoding, switch to a better host if it bothers you so much. [It's odd, your servers identify as "Apache/1.3.26 (Unix) PHP/4.2.2 mod_gzip/1.3.19.1a" -- mod_gzip is there but your host isn't permitting usage?]
Feel free to email me at monkeyman at oswd.org if you want to discuss it more.
Look, it may seem like I'm coming down on you like a ton of bricks. That's because I am.
It frustrates me to encounter Slashbots who insist on posting with the +1 bonus (even deep in a now off-topic thread), forcing an escalation to my own bonus. It frustrates me to read about how everyone should be beholden to one person's experience, when that person argues in the same thread that individual experiences don't matter much in the face of aggregate counts. And when that person needlessly crows about search engine placement. And especially when he attempts to push a public discussion off to email when someone takes the time to respond in kind.
TheCounter serves up a hell of a lot more stats than you or I though.
That does not mean TheCounter's methodology is
automatically sound in terms of properly ID'ing
browsers or capturing a representative sample of
the entire browsing popularion. Big numbers are
not always better numbers.
[Zeldman] complain[s] about [...] extra html caus[ing]huge bandwidth charges, which I can assure you are negligible [...] If you take a look at my August statistics [...] you can see me panicking about bandwidth and switching our old font tags to CSS. You can see the page views are about the same [...] but the bandwidth goes from 871megs to 838megs. 40 megs is a very small difference for possibly breaking browsers that don't support CSS!
I think you're missing the point. Zeldman (and
believe me, I really have no love for the man or
his work, by and large) argues for a more holistic
approach to implementation. It's not about simply
dropping FONT elements in favor of CSS rules. It
is about examing existing markup in order to use
HTML in a semantic manner. Use H1-H6 for headings
instead of FONT elements combined with B, I, EM,
STRONG, BIG, etc. Apply CSS rules to meaningful
elements (e.g., CITE, ADDRESS, etc.) instead of
throwing SPAN and DIV elements in there simply to
affix style rules. Learn how to use CSS selectors
properly instead of defining multiple classes for
each element (e.g., define a markup template that
permits mapping to CSS rules which define styles
for nested element combinations).
I don't know enough about your particular site to
say for certain what you did or did not do, but it
sounds as though you took away one part of Z's
offered solution ("Ditch the FONT element!") but
ignored the remaining message. Your choice, but
don't indict the argument for complete renovation
on the basis of limited action. [Although I do now see that you seem to enjoy using SPAN elements.]
With regards to the "small difference", I see that
your numbers correspond to a 3% to 4% reduction in
bandwidth usage when using uncompressed transfers.
I only wish it were so easy to reduce all potential
operation costs by that amount. Any reduction in bandwidth
charges is a gain. Adopting a semantic approach to
markup eliminates the risk of "breakage" for those
using CSS-intolerant browsers. Using CSS smartly
reduces the risk of "breakage" for those using
CSS-stupid (i.e., NN 4.x and IE 4.x) browsers. A
cut in bandwidth usage is a cut in bandwidth usage,
I don't see what you're complaining about.
Of course, there are other factors to consider in
evaluating your switch. Was the application of CSS
efficient? Are there cache-control directive that
should be taken into account? Are there cache-control directives that ought to be put into place? Did you really make an effort to rethink your approach to markup, or was this simply a stop-gap solution?
There's nothing wrong with looking for a quick fix to the particular problem you faced. There's no arguing that compressed file transfers obviously gave to you greater gain, and that you felt it's loss sharply at the time. However, I believe that
Z wants people to taking a long look at their own
practices, and consider markup from the inside-out.
It's not about dropping FONT elements in favor of
SPAN elements with associated class selectors. If you, yourself, don't have the time or care for that, don't complain that it won't work for others. Your case is not representative of that for which Zeldman argues.
That being said, I still find Z full of much hot
air, myself. On this, though, he is mostly correct.
In my opinion, that is.
You are right to point out the bandwidth that is
associated with image transfer. Of course, that,
too, can be battled by choosing proper image
formats, limiting graphic usage only to what is
truly necessary to design, and understanding the
role of cache directives. It's a salient point,
but does not diminish the significance of looking
at "the whole package" in Web implementation.
Even better, is when they get comfortable running Opera / Mozilla, they'll be more willing to try OpenOffice instead of M$ Office, and then you're 75% of the way there (if not more) to getting them to dump Windows altogether.
That's nice and all, but why does the eventual
goal always have to involve dumping all Microsoft
products out the window? Now, I, too, try to convince others that Mozilla-based browsers offer
a pile-and-a-half of features that MSIE doesn't.
I do it not to dislodge them from Windows
(with which most are content) but to provide them
with the better browser.
Have I missed the point in leaving it at that,
or have you in not?
The only things that balk at running in Classic are a few old games.
And if this is truly the case, Microsoft leads the
way again, in that WinXP balks at running a "few old games" in its emulation (or whatever) of DOS.
Etc. Apple isn't stepping out of line with this press release. They're just being up-front about it.
Of course, I don't see anyone else pointing this out. Perhaps there are bigger fish to fry when it
comes to Microsoft's operating systems. Perhaps it
was time for/. to host a rant-fest railing against
Apple's. Whatever.
DOS -> WinXP may be a farther leap than OS 9.x -> OS 10.x (by comparison), but it's still the same core issue of when and where to cut the cord in handling legacy applications for a given platform.
Meanwhile, Linuxians are there, ever-ready to support yet another dead or dying set of software through emulation (or whatever). More power to them, I guess, though I would think there are plenty of Linux-specific apps in equal need of attention.
[Required minimum system software versions to boot] lets Apple gradually get rid of legacy hardware in a computer, something the PC side can't seem to do for some reason.
I cannot tell whether you're being facetious
or not, but ("Hey! I'll take a stab in the dark.")
I think it has something to do with not being
in control of both hardware and software at
once. Apple sells a more unified product. PC
vendors (generally) do not. Apple has the ability
to leverage their control of both sides of the
equation ('ware, soft- and hard-). Not to do so would be foolish, indeed.
[Eric's design] was complicated. It included an entire theorem prover. This was sort of cool in that it would not allow you to generate a non-working configuration, but really more than was required for the job.
I grasp the significance of the other three points
of contention you mention, but the fourth (above)
doesn't jump out and grab me as an issue in and of
itself. On the one hand, it may be that the method
was overly complex (evidenced in part by the Python
requirement and an unfamiliar idiom). Disallowing an
unworkable configuration doesn't seem unreasonable,
though. Is there a down-side to building that
safety into the configurator apart from any flaws
[heightened complexity] in Eric's particular implementation?
The $1500 price is entry-level for the HP
model. According to the article, Samsung
will also manufacture these entertainment PCs. Who
knows, maybe they'll offer the product at
a lower price point.
'Freestyle' refers to the version of Windows
to be used (now 'Window XP Media Center Edition'), not the actual manufactured boxes.
Also, news.com reports that both HP and
Samsung models will be available *before*
Christmas season. Apparently even story
submittors have stopped reading the articles.:P
My only concern would be the following: If was a company like Sony and I did some R&D to improve the quality of ogg files in order to give my products a competative edge over other brands, would I have to make those improvements open source?
RTFL:
Copyright (c) 2002, Xiph.org Foundation
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:
- Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
- Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the distribution.
- Neither the name of the Xiph.org Foundation nor the names of its
contributors may be used to endorse or promote products derived from
this software without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR
CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
One of the contributors described watching small plastic bags circulating in wind pockets, commenting that "sometimes there's so much beauty in the world, I just can't take it".
It certainly doesn't read as though he got
the joke.
Anyone ever wonder how useful that sidebar
actually is, given the lack of context and
(possibly) the lack of forethought on the
part of submitters/editors?
Take this story for example:
"concluded", "asking", and "previously"
compared to the more reasonable
link text of "single electron"
(still unclear) and "applets and demonstrations".
The one thing I like the look of is P3P support. A little shocking that IE got this long before anybody else.
But it's not terribly shocking that Microsoft's P3P implementation wasn't (isn't?) entirely up to snuff (see: SuperCookies).
This is somewhat humorous, given that support for
P3P in IE 6.0 solely concerns cookie use, and not much (if anything else) in the W3C Recommendation
(see: P3P: Privacy Primer).
Some support (IE 6.x) is probably better than no support (NN 7.x), but there is no P3P implementation for either the Mac or *nix versions of Internet Explorer. So, while I'm willing to admit that Microsoft is trying, I'd continue to ask that they try a bit harder in the future.
Re:I wonder what slashdot's percentages are....
on
Netscape 7.0 is Out
·
· Score: 2
Konqueror is the only browser on this planet that reopens all the links just like they were yesterday when I logged out. All on the right desktop with the right window-dimensions.
I won't say you are wrong, I'll merely suggest that
you might be mistaken. I recall way back when there
was I time I tinkered with Opera 3.x (possibly 4.x)
and it would "reopen" the links that were "there
yesterday" just fine. Of course this was back when
the MDI design was mandatory for Opera, so there
was really only one window open at once -- with multiple subviews -- and hence, only one window dimension in effect for all viewed documents.
I would be surprised to find that Opera no longer behaves in this manner.
Then again, I'm too lazy to reinstall 6.x and test my hypothesis.:P
Slashdot Mirror
I thought they fucked up by not including the normal cut of the film on one of the discs [...] I really prefer the non-Director's-edition.
MPAA to blincoln: Our hearts go out to you in your time of need. Now go out and buy both releases. Links have been supplied to ease your pain.
Original Cut
Director's Cut
End transmission.
[Y]es, [cleaning out markup cruft] can make a pretty big difference with uncompressed html, it makes little difference when gzip gets back in the game.
True, but I don't understand why you continue to set up a comparison between the markup with which a document is fashioned and the method by which it is delivered. Both offer savings. Your original example was what you did when you couldn't compress the data and how that somehow disproves the argument that markup reconsideration offers no benefit to those implementing Web sites. In setting up a comparison between delivery and design, you stray from your original point, obscuring the thread of reasoning to which most seem to be responding here.
Another tidbit for your consideration: Although the data may be compressed on transfer, it usually is not stored in a compressed format within clients' caches. There are even a lot of clients in use that don't accept compressed data feeds. And there are a lot that neither accept, nor store, compressed data. One particularly relevant example set would be all those lightweight Windows CE devices that have been on the market for years. Speaking from experience, my incredibly useful Aero 8000 doesn't benefit much from data compression, and given that its memory is only 64 MB for OS + apps + data, I (as a user) don't appreciate cloggy Web documents. I guess that's the risk we all run when visiting sites we didn't build ourselves, eh? :)
But if you look at other posts around this thread, that accounts for less than a buck a year.
I'm the only one on the design team that works almost exclusively in CSS. The current design on the site wasn't made by me, the old one wasn't either.
Then I would suggest that it was a pretty poor example to use, or rely upon, to demonstrate a real-world challenge to Zeldman's case.
You can get a better idea of my CSS style by going to a css layout version of our current design or my not close to being done SVG site. Which has a very clean body.
It's unfortunate that the layout version isn't close to valid HTML or that the CSS isn't much better. The markup for the SVG site is a bit better, though the validator doesn't catch the odd inclusion of XHTML style BR elements in a document clearly marked as HTML 4.01 Transitional. I'll leave a check of its CSS to you, I'm getting timeouts on multiple requests to your server. You may want to investigate its cache status, too. But I assume both are incomplete projects, and everyone makes mistakes (though why they would post them to /. is beyond me).
The change was to pretty basic CSS and worked fine in all browsers. Although it still wasn't *exactly* what the old version looked like (text a couple points off here and there).
I suspect that the search for pixel- and proportion-perfect design is a root issue. Thinking in those terms when implementing on the Web is troubling and could even be labeled by some as naive or impossible beyond the narrowest of visitor communities. I begin to understand the excessive use of DIV elements in your markup.
[A]s I pointed out 3-4% is only 40megs. We pay $10 for 10 gigs of transfer and the account on the machine. So 40 megs is less than 5 cents. Hardly anything compared to the 400% difference of having gzip turned off.
Bandwidth is a resource, and like any resouce, it ought to be conserved where possible. Read my original post where I anticipate (and do not contest) a return to the issue of transfer compression. You don't have sufficient traffic to worry about cutting even small chunks from your costs, fine. Don't indict the practice for everyone else then ("I can assure you [bandwidth savings] are negligible.") or just send me the five cents you will sav every day, I'll put it to good use. :p
The point is this: you still seem to be glossing over my earlier observation that your ~4% savings could have been even greater had you actually understood the holistic approach Zeldman offers. It troubles me to think that you still don't "get it", even though you offer a couple new example sites that would seem to suggest that you do, in part.
If I were on dial-up (which thankfully, I'm not at the moment), I would certainly be appreciative as a user for the additional savings in time and bytes. Yes, there are still people on metered plans out there in the world. How much bandwidth a document or a site needs is not only a cost for the supplier, but also for the consumer, in money and time.
No one is contesting the utility of transfer compression. Stop complaining about the lack of gzip encoding, switch to a better host if it bothers you so much. [It's odd, your servers identify as "Apache/1.3.26 (Unix) PHP/4.2.2 mod_gzip/1.3.19.1a" -- mod_gzip is there but your host isn't permitting usage?]
Feel free to email me at monkeyman at oswd.org if you want to discuss it more.
Look, it may seem like I'm coming down on you like a ton of bricks. That's because I am.
It frustrates me to encounter Slashbots who insist on posting with the +1 bonus (even deep in a now off-topic thread), forcing an escalation to my own bonus. It frustrates me to read about how everyone should be beholden to one person's experience, when that person argues in the same thread that individual experiences don't matter much in the face of aggregate counts. And when that person needlessly crows about search engine placement. And especially when he attempts to push a public discussion off to email when someone takes the time to respond in kind.
Best of luck in your quest to regain mod_gzip.
TheCounter serves up a hell of a lot more stats than you or I though.
That does not mean TheCounter's methodology is automatically sound in terms of properly ID'ing browsers or capturing a representative sample of the entire browsing popularion. Big numbers are not always better numbers.
[Zeldman] complain[s] about [...] extra html caus[ing]huge bandwidth charges, which I can assure you are negligible [...] If you take a look at my August statistics [...] you can see me panicking about bandwidth and switching our old font tags to CSS. You can see the page views are about the same [...] but the bandwidth goes from 871megs to 838megs. 40 megs is a very small difference for possibly breaking browsers that don't support CSS!
I think you're missing the point. Zeldman (and believe me, I really have no love for the man or his work, by and large) argues for a more holistic approach to implementation. It's not about simply dropping FONT elements in favor of CSS rules. It is about examing existing markup in order to use HTML in a semantic manner. Use H1-H6 for headings instead of FONT elements combined with B, I, EM, STRONG, BIG, etc. Apply CSS rules to meaningful elements (e.g., CITE, ADDRESS, etc.) instead of throwing SPAN and DIV elements in there simply to affix style rules. Learn how to use CSS selectors properly instead of defining multiple classes for each element (e.g., define a markup template that permits mapping to CSS rules which define styles for nested element combinations).
I don't know enough about your particular site to say for certain what you did or did not do, but it sounds as though you took away one part of Z's offered solution ("Ditch the FONT element!") but ignored the remaining message. Your choice, but don't indict the argument for complete renovation on the basis of limited action. [Although I do now see that you seem to enjoy using SPAN elements.]
With regards to the "small difference", I see that your numbers correspond to a 3% to 4% reduction in bandwidth usage when using uncompressed transfers. I only wish it were so easy to reduce all potential operation costs by that amount. Any reduction in bandwidth charges is a gain. Adopting a semantic approach to markup eliminates the risk of "breakage" for those using CSS-intolerant browsers. Using CSS smartly reduces the risk of "breakage" for those using CSS-stupid (i.e., NN 4.x and IE 4.x) browsers. A cut in bandwidth usage is a cut in bandwidth usage, I don't see what you're complaining about.
Of course, there are other factors to consider in evaluating your switch. Was the application of CSS efficient? Are there cache-control directive that should be taken into account? Are there cache-control directives that ought to be put into place? Did you really make an effort to rethink your approach to markup, or was this simply a stop-gap solution?
There's nothing wrong with looking for a quick fix to the particular problem you faced. There's no arguing that compressed file transfers obviously gave to you greater gain, and that you felt it's loss sharply at the time. However, I believe that Z wants people to taking a long look at their own practices, and consider markup from the inside-out. It's not about dropping FONT elements in favor of SPAN elements with associated class selectors. If you, yourself, don't have the time or care for that, don't complain that it won't work for others. Your case is not representative of that for which Zeldman argues.
That being said, I still find Z full of much hot air, myself. On this, though, he is mostly correct. In my opinion, that is.
You are right to point out the bandwidth that is associated with image transfer. Of course, that, too, can be battled by choosing proper image formats, limiting graphic usage only to what is truly necessary to design, and understanding the role of cache directives. It's a salient point, but does not diminish the significance of looking at "the whole package" in Web implementation.
Who on earth is running a browser earlier than 4.x [...] Don't you have to try real hard to even find an older version of any of these browsers?
Nah. I just go over to my sister's house and see what she happens to be using to access the Web...
What we really want to know is when is the spelling going to change from "Nex II" to "Nex ][" or "Nex //"
Genius. Sheer genius.
The NexII got good reviews on slashdot (Review: Nex II CF MP3 Player) a while back and now a newer version named the NexIIe is shipping.
You can keep your Nex II and even your Nex IIe.
I, and several others are waiting for the obvious successor: the IIc.
Apache supports a jillion languages, why doesn't mozilla?
Care to elaborate on the reasoning behind that juxtaposition?
Or, care to explain why it should be considered as cementing the position you seem to have adopted?
I haven't tried myself, but doesn't CSS support this sort of thing nicely?
Only to the extent to which the application in question supports the level of CSS required. Aye! The rub! The rub!
Even better, is when they get comfortable running Opera / Mozilla, they'll be more willing to try OpenOffice instead of M$ Office, and then you're 75% of the way there (if not more) to getting them to dump Windows altogether.
That's nice and all, but why does the eventual goal always have to involve dumping all Microsoft products out the window? Now, I, too, try to convince others that Mozilla-based browsers offer a pile-and-a-half of features that MSIE doesn't. I do it not to dislodge them from Windows (with which most are content) but to provide them with the better browser.
Have I missed the point in leaving it at that, or have you in not?
The only things that balk at running in Classic are a few old games.
And if this is truly the case, Microsoft leads the way again, in that WinXP balks at running a "few old games" in its emulation (or whatever) of DOS. Etc. Apple isn't stepping out of line with this press release. They're just being up-front about it.
Of course, I don't see anyone else pointing this out. Perhaps there are bigger fish to fry when it comes to Microsoft's operating systems. Perhaps it was time for /. to host a rant-fest railing against
Apple's. Whatever.
DOS -> WinXP may be a farther leap than OS 9.x -> OS 10.x (by comparison), but it's still the same core issue of when and where to cut the cord in handling legacy applications for a given platform.
Meanwhile, Linuxians are there, ever-ready to support yet another dead or dying set of software through emulation (or whatever). More power to them, I guess, though I would think there are plenty of Linux-specific apps in equal need of attention.
[Required minimum system software versions to boot] lets Apple gradually get rid of legacy hardware in a computer, something the PC side can't seem to do for some reason.
I cannot tell whether you're being facetious or not, but ("Hey! I'll take a stab in the dark.") I think it has something to do with not being in control of both hardware and software at once. Apple sells a more unified product. PC vendors (generally) do not. Apple has the ability to leverage their control of both sides of the equation ('ware, soft- and hard-). Not to do so would be foolish, indeed.
Or how to flash your tits so that they point to your wishlist?
In a word: classic.
You, sir, are a poet.
[H]as Ellen Feiss became some kind of new geek sex symbol[?] [...] I'm just wondering how much out of the loop I am.
Very.
[Eric's design] was complicated. It included an entire theorem prover. This was sort of cool in that it would not allow you to generate a non-working configuration, but really more than was required for the job.
I grasp the significance of the other three points of contention you mention, but the fourth (above) doesn't jump out and grab me as an issue in and of itself. On the one hand, it may be that the method was overly complex (evidenced in part by the Python requirement and an unfamiliar idiom). Disallowing an unworkable configuration doesn't seem unreasonable, though. Is there a down-side to building that safety into the configurator apart from any flaws [heightened complexity] in Eric's particular implementation?
[D]oes that knowledge base entry look like shit in Mozilla? [T]his time the text is all squished together...unreadable.
Same here with a recent nightly of Mozilla [Build ID: 2002090316].
Too lazy to view the source of the document just now, though.
The $1500 price is entry-level for the HP model. According to the article, Samsung will also manufacture these entertainment PCs. Who knows, maybe they'll offer the product at a lower price point.
'Freestyle' refers to the version of Windows to be used (now 'Window XP Media Center Edition'), not the actual manufactured boxes.
Also, news.com reports that both HP and Samsung models will be available *before* Christmas season. Apparently even story submittors have stopped reading the articles. :P
My only concern would be the following: If was a company like Sony and I did some R&D to improve the quality of ogg files in order to give my products a competative edge over other brands, would I have to make those improvements open source?
RTFL:
Quoting you, quoting him:
One of the contributors described watching small plastic bags circulating in wind pockets, commenting that "sometimes there's so much beauty in the world, I just can't take it".
It certainly doesn't read as though he got the joke.
Anyone ever wonder how useful that sidebar actually is, given the lack of context and (possibly) the lack of forethought on the part of submitters/editors?
Take this story for example: "concluded", "asking", and "previously" compared to the more reasonable link text of "single electron" (still unclear) and "applets and demonstrations".
Flame away, but someone had to ask.
The one thing I like the look of is P3P support. A little shocking that IE got this long before anybody else.
But it's not terribly shocking that Microsoft's P3P implementation wasn't (isn't?) entirely up to snuff (see: SuperCookies). This is somewhat humorous, given that support for P3P in IE 6.0 solely concerns cookie use, and not much (if anything else) in the W3C Recommendation (see: P3P: Privacy Primer).
Some support (IE 6.x) is probably better than no support (NN 7.x), but there is no P3P implementation for either the Mac or *nix versions of Internet Explorer. So, while I'm willing to admit that Microsoft is trying, I'd continue to ask that they try a bit harder in the future.
Konqueror is the only browser on this planet that reopens all the links just like they were yesterday when I logged out. All on the right desktop with the right window-dimensions.
I won't say you are wrong, I'll merely suggest that you might be mistaken. I recall way back when there was I time I tinkered with Opera 3.x (possibly 4.x) and it would "reopen" the links that were "there yesterday" just fine. Of course this was back when the MDI design was mandatory for Opera, so there was really only one window open at once -- with multiple subviews -- and hence, only one window dimension in effect for all viewed documents.
I would be surprised to find that Opera no longer behaves in this manner.
Then again, I'm too lazy to reinstall 6.x and test my hypothesis. :P
Whats a tentacle?
(its a really obsucre reference)
Obscure?
The google alogorithm can be manipulated to some extent but it has stood up pretty well so far.
Blogs must be denting the system, at least for specific queries against Google. Check out the "Kate Bosworth naked" war, for instance.