Yeah, actually we have. If you're trying to get lists to render properly on Opera6 then you'll need to tweak your stylesheet specifically for that browser to move those lists 38 pixels to the left. In order to do this you'll probably have to check for 'Opera' in the user-agent string. Of course, when Opera fixes this problem and thus renders the -38px offset correctly you'll have to change your user-agent parsing to handle the new version number.
actually their assessment of 'just fine' is incorrect.
there is a non-standard 38 pixel indentation that Opera6 applies to lists. the change in the stylesheet is designed to overcome this bug. the rendering in Opera6 may look 'just fine' but in fact there's extra space in there that shouldn't be.
the fix in Opera7 means that the stylesheet causes the list to be indented 38px to the left.
remember that v7 was only release last week. the page in question appears to render correctly on the previous version (although it's just a bug in the browser hiding the bug in the stylesheet).
actually the same stylesheet is sent to Opera v6 browsers which render the (admittedly buggy) page incorrectly. it just so happens that this incorrect rendering hides the bug in the stylesheet and thus the page appears as desired. it's only since the rendering bug was fixed in v7 that the stylesheet bug has become apparent, and since v7 was only released last week, it's a little premature to assume that the bug in the stylesheet is deliberate.
Yeah but the stylesheet for opera is designed to work with Opera v6. The bug in the stylesheet was hidden by a bug in v6 which was only last week fixed in v7. sure, there's a bug in the stylesheet, but that doesn't mean it's new or that it was placed there specifically to break Opera v7.
i gues it depends on how much of the rendering process you want to perform on the video hardware. again, since he's talking high-end i assumed he mean most of it.
unfortunately the 7505s only support DDR266 which is only just sufficient to supply the 533MHz FSB CPUs. When you add the 2.1GB/s requirement of the AGP8x port on top of that you start biting into your efficiency. let's hope they come out with a 333/400 solution soon.
also, is it me or is anyone else pissed that since the introduction of the P4 intel has stopped dualie support on their desktop line? i still have fond memories of my dual-hacked-celeron/300a++ setup. anyone remember the 440BX? damn that thing lasted for years, now we seem to get a new chipset every few months...
speaking of which, what's up with AMD & their dual proc story. is just one MP chipset in 2 years enough? i think not...
This is definitely the case for most applications where 128MB easily covers the texture requirements and the only speedup seen is for vertex/instruction buffers. However he specifically states that he's doing high-end graphics and video editing, in which case it's quite reasonable that the increase in bandwidth that 8x provides could significantly improve performance. Remember: games are specifically tuned so that most of the textures remain on the card for significant amounts of time. For example, they design the levels so that at any given position all of the textures necessary to render the surrounding environment and any additional features (characters, weapons, effects, overlays, etc...) will fit in VRAM. However, if you're using a 3d modelling package to create arbitrarily complex environments you can quite easily exceed the VRAM on your card for a single render. At this point bandwith is key, and it is these kinds of situations where specifically-designed graphics workstations (eg. SGI) mop the floor with your $400 games cards.
FYI: you should be able to download the latest Platform SDK from microsoft which includes the latest build tools. It doesn't have MFC/ATL, but you should be able to still use the versions from VC6 with the new compiler/linker.
You should be using the Microsoft Baseline Security Analyzer
to ensure that ALL the machines on your network are properly patched and locked down. It's so easy to run there should be no excuse for attacks like this.
Errr... no. If you took the time to actually look at the Mono Home Page you'll see that the goal is to implement almost all of the.NET libraries, including ADO.NET, ASP.NET, XML, Web Services, Remoting, etc... The only parts that Ximian isn't interested in doing are Windows.Forms and COM interop, but they're certainly not discouraging others to contribute those to the Mono project.
Slashdot Mirror
ugh, i suggest you research fully the relevant bug in Opera6 and then comment on the required work-around.
d) the -38px adjustment is in there to overcome a non-standard +38px adjustment that Opera v6 adds to lists.
does 'well enough' include a 38 pixel indentation of lists when you specify IE6 as the user agent?
moderation: +20 (possibly the only insightful post in this discussion)
there is a non-standard 38 pixel indentation that Opera6 applies to lists. the change in the stylesheet is designed to overcome this bug. the rendering in Opera6 may look 'just fine' but in fact there's extra space in there that shouldn't be.
the fix in Opera7 means that the stylesheet causes the list to be indented 38px to the left.
remember that v7 was only release last week. the page in question appears to render correctly on the previous version (although it's just a bug in the browser hiding the bug in the stylesheet).
actually the same stylesheet is sent to Opera v6 browsers which render the (admittedly buggy) page incorrectly. it just so happens that this incorrect rendering hides the bug in the stylesheet and thus the page appears as desired. it's only since the rendering bug was fixed in v7 that the stylesheet bug has become apparent, and since v7 was only released last week, it's a little premature to assume that the bug in the stylesheet is deliberate.
Yeah but the stylesheet for opera is designed to work with Opera v6. The bug in the stylesheet was hidden by a bug in v6 which was only last week fixed in v7. sure, there's a bug in the stylesheet, but that doesn't mean it's new or that it was placed there specifically to break Opera v7.
However the same page is returned when using Opera v7 which renders the page differently.
It's not surprising that msn hasn't tested their pages on Opera v7, which, as far as I can tell, was released last week .
This is nothing more than Opera fishing for press coverage for their new browser. And it's a pretty juvenile attempt at that.
I got one word for ya: 'decaf'
who's the putz, again?
also, is it me or is anyone else pissed that since the introduction of the P4 intel has stopped dualie support on their desktop line? i still have fond memories of my dual-hacked-celeron/300a++ setup. anyone remember the 440BX? damn that thing lasted for years, now we seem to get a new chipset every few months...
speaking of which, what's up with AMD & their dual proc story. is just one MP chipset in 2 years enough? i think not...
This is definitely the case for most applications where 128MB easily covers the texture requirements and the only speedup seen is for vertex/instruction buffers. However he specifically states that he's doing high-end graphics and video editing, in which case it's quite reasonable that the increase in bandwidth that 8x provides could significantly improve performance. Remember: games are specifically tuned so that most of the textures remain on the card for significant amounts of time. For example, they design the levels so that at any given position all of the textures necessary to render the surrounding environment and any additional features (characters, weapons, effects, overlays, etc...) will fit in VRAM. However, if you're using a 3d modelling package to create arbitrarily complex environments you can quite easily exceed the VRAM on your card for a single render. At this point bandwith is key, and it is these kinds of situations where specifically-designed graphics workstations (eg. SGI) mop the floor with your $400 games cards.
the real question is why aren't you willing to work for $7.01 or less?
FYI: you should be able to download the latest Platform SDK from microsoft which includes the latest build tools. It doesn't have MFC/ATL, but you should be able to still use the versions from VC6 with the new compiler/linker.
It would be nice to see the same comparisons but with compilers that aren't over 3 years old.
ouch. you're not using exchange, i take it?
do you have windows authntication enabled for SQL server, and are you a member of the SQL admins group?
You should be using the Microsoft Baseline Security Analyzer to ensure that ALL the machines on your network are properly patched and locked down. It's so easy to run there should be no excuse for attacks like this.
!!!ATTENTION MS ADMINS!!!
I get 1.1s (0.3s startup time) for .NET on my pIII/550MHz.
that bug was fixed.