RTFA. The article says that the major players would be Linux and Windows, not the only players. Apple isn't interested in being a big player; they're interested in being a high margin high profit player.
If I were a resident of WA, I'd want to kick the politicians out first. They're the ones spending billions of dollars to construct a monorail that only runs a few miles. Where simple road projects span hundreds of million dollars. Where they build billion dollar stadium after stadium for sports teams -- the latest being building a frick'in race track. Taxes don't need to be increased to fix the education system in WA, the politicans just need to have their credit cards torn up.
Wait, I am a resident of WA... maybe I'll help do that in November...
With the kind of forces involved in a large volcanic erruption, I would be very suprised if there wasn't a ton of advanced warning. A perfect example is Mt. St. Helens '80 erruption. The sucker was building up for quite some time before it blew.
Hell, we had over a weeks notice before this tiny event...
However, you must first be attempting to leverate your monopoly to abuse that position. A media player has shipped with every version of Windows since the 3.x days. It was included before they were a monopoly. Their media player doesn't have a monopoly on the media player market after obtaining a monopoly in the OS market.
The only logical conclusion is that the mere act of bundling a media player with the operating system does not give them a monopoly on the media player market.
You certainly can't conclude that they're attempting that now when they havn't change their actions in 15 years...
There is one flaw with your arguement. Windows has ALWAYS shipped with a media player in one form or another (since the windows 3.x days). If their media player didn't obtain a monopoly during the period that Windows obtained a monopoly, shipping a media player with the OS is obviously not sufficient to monopolize the media player market. Therefore, the act of bundling a media player with an operating system cannot be construed as an attempt to monopolize the media player market.
I know a guy with a clown camera. I've seen the prints from it. For the sizes you were talking about, I can't tell a difference unless he breaks out a magnifying glass. I generally look at a picture, not parts of it through a magnifying glass.
For large prints there is definately a difference, but for the smaller sizes you were referring to I can't.
In my experience, people making statements like this don't consider a print "quality" unless they can look at the print with a magnifying glass and see detail you can't see with the naked eye...
JPEG/TIFF usually store 24 bits per pixel, or 8 bits per channel. TIFFs can store more than 8 bits per channel (I've used software which will read/save TIFFs with 16 bits per channel, or 48 bits per pixel).
The problem with saving a "normal" TIFF image is that you have to process the raw data and produce and RGB image from it, which means you take up roughly 3-4x (depending on the sensor if they consider the green data to be in two separate channels) as much space than you would if you just save the raw data.
Also, as mentioned already, settings such as white balance, tone, sharpness, color, and even exposure compensation can be applied after the shot was taken.
You can do this with a JPG or TIFF image - however your final result won't be as good.
Office 2003 and.NET Framework 1.1 were vulnerable, but if you had applied PREVIOUSLY AVAILABLE updates to either of those products, then, in fact, they weren't
Office 2003 and.Net Framework 1.1 are vulnerable. Office 2003 SP1 and.Net Framework 1.1 SP1 are not (the service packs are your 'previously available update'). Microsoft refers to service pack levels when specifying which products are and are not vulnerable. Lack of a sp level indicates a product without a service pack applied.
Raw images from the Nikon D70 hover around 2-6mb. As the images are compressed (pseudo losslessly; Nikon compresses the highlight information to 10bits), the size varies.
If you do any post processing, raw + 16bpc imaging tools are the way to go.
Unfortunately, "get it right the first time" isn't possible because you don't have a laptop sitting next to you to examine the image in every fine detail.
The biggest advantage digital cameras give you over film is the flexability to NOT get it right the first time. Aside from the power to take a large number of shots to experiment with ideas you wouldn't otherwise give the time of day, it also allows you to fix things you didn't notice when you did take the image. If you just want to shoot once and hope it turns out the way you imagined, don't bother getting a dslr.
A lot can be done to process an image after capturing it, and the extra few bits of information make a huge difference in the final quality of the image. Add into the equation a sharper image and better color (jpgs seem to 'compress' the red channel more than others...). Not to mention the advantage it gives you if you decide to work in a colorspace other than sRGB (ie: more accurate color when transforming to the printer's colorspace).
Yeah. Most of us refuse to consider the possibility because it's utterly stupid.
I can imagine that similar things were said when it was suggested that the Earth wasn't at the center of the universe and that everything didn't revolve around it.
Disprove his evidence instead of mocking it as "stupid" and inconceivable.
I've never seen lag like that caused by an LCD and I can't imagine how the electronics could create that effect.
The demonstration video showed the LCD off by 1 or 2 frames. Nobody would notice that kind of delay unless the LCD were placed next to a CRT in a multi-mon configuration. And hey, guess what this guy did?...
At 30fps, that delay would be 33 to 66ms. The LCD switching speeds in monitors these days seem to range between 16 to 20ms. So, question is, can you realistically introduce another 13 to 50ms? Don't forget to include the A2D converters and circuitry designed to compensate for mismatching the refresh rate from the preferred rate...
Like another post already said, the LCD would need a screen data buffer of several megabytes and it doesn't have one.
You don't need a large data buffer to see that kind of effect, you just need a long enough data pipeline.
The dude has a video of multimon setup demonstrating the 'lag'. If it were mouse drivers both screens would draw at the same rate.
I'm going to presume that he was smart enough to test the same setup with a CRT to see if the problem persists to rule out the video card/drivers, but you never know...
This isn't about rating machines for sale, it's about making it easy for the home user to determine if a piece of software will run on the machine they already own.
It isn't meant for people like you, because you already know what all of the terms are and how they relate to each other. Joe Schmoe who buys his computer at Walmart doesn't know the difference between RAM and HD space, let alone that a 2ghz P4 is way slower than a 2ghz Athlon...
We have exactly that. The problem is that the average consumer doesn't know what any of those specs represent, has no idea what is inside their computer, and really doesn't know if their computer can really run the software they are buying (they just assume it will).
Hell, I have problems reading through the system requirements... they're usually on the bottom of the box in a 4pt font...
While it would be technically possible to overcome these problems by upping the bandwidth allocated to each individual station
The other way to do it would be to have a few additional tuners recording the stream from the next and previous channels so you have a stream ready to use when you flip through channels... This would be an optimal way to use the extra tuners used for pip built into the fancy tv's that allow like 2 or 3 pip displays on screen at once.
The OS doesn't come to a screeching halt. It continues working just fine. The poorly programmed application starts behaving badly, essentially making it useless. Instead of telling people how to restart the application in question, they apparently found it easier to tell people to hit the reset button instead.
Then you break backwards compatibility with all of the existing applications that call that API. Compiled code doesn't tend to work nicely when it expects 4 bytes on the stack and gets 8 bytes instead.
If your code can't deal with a rollover condition, you should be calling GetSystemTime instead. Typically, the reason why people call GetTickCount instead of GetSystemTime is generally due to lazyness (it's harder to "sort" the system time structure than a dword).
It doesn't reboot immediately -- you can see the machine bluescreen; it remains bluescreened until it writes out a minidump of the operating system state. It also adds an entry into the eventlog to record the crash. THEN it reboots.
Personally, it seems to be really stupid to leave a machine (that may or may not be responsible for some critical service) in a crashed state when it can be rebooted automatically.
The only time I've ever gotten blue screens on my machine was when I was playing around with overclocking my machine. Backed the timings off to spec and haven't had one single crash since.
Once I had finished the install, the online update installed a couple of security patches that downloaded in about 10-20 minutes over my modem link.
This was my biggest problem with the install actually. It presented a huge list of locations to download patches from. The first five I selected (at random, because duh, which one is a good one to pick?) didn't work. There were also 2 or 3 poorly worded checkboxes, each which was ambiguous to the point where I wasn't sure if selecting or not selecting the checkbox would cause patches to actually be downloaded and installed. I decided leaving them alone would be the safest.
After that, I click whatever button there was that tells the thing to start, and proceed to spend the next 2 hours (via cable modem) waiting for patches to download. I eventually gave up and went to bed -- the next morning I discover that an error occured during part of the process and it stopped (not too long after I left it alone for the night, as the progress bar hadn't moved that far). What the error was, I couldn't tell you. What I was supposed to do about it, I couldn't tell you either -- the only rational options were a. reinstall from scratch and try again or b. continue with the install and hope that some other process would update it properly next time or that I'd figure out how to do it myself. The "error" sure as hell didn't suggest anything on the issue.
Don't even get me started about the mess that was setting up KDE or X or whatever the hell it did afterwards...
With XP, the install took a similar amount of time, but I additionally had to install several other applications that took about 10-20 minutes each to achieve the same level of functionality.
Yeah, net "install" time with that factored in (ie: time to install applications) is probably much closer, though I can't remember the last time it took me 10-20 minutes to install an application aside from Visual Studio.
and I had to reboot twice in order to install everything (the Linux updates did not require a reboot).
I don't get what the obcession over reboots is... yeah, for a server that is in production they suck, and that is a valid complaint, but setting up the machine initially? It isn't like XP takes 15 minutes to boot...
I'm not an idiot... if I really wanted to, I could spend the time figuring out how to get stuff done right (once upon a time I had an m68k version of the kernel running on an Atari TT030). Back when I was in college, I had all the time in the world fiddling and twiddling with things. Problem is, I don't have that kind of time anymore -- I just want to use the darn thing.
installing linux on hardware that's on the HCL is trivial and takes half the time of Windows
You are ON CRACK if you think that installing Linux is trivial. Given the inconsistent, poorly worded, in some cases confusing text presented during Linux distro installs I'll take the XP cd any day of the week.
Same comment applies to install time... if you choose a minimal install, it takes very little time to install -- however, you have to take the time and frigging deselect everything that is preselected for you, and then go through the million dialogs saying "xyz depends on this library" and turn a bunch of things back on you way in the negative as far as install time goes. If you choose a default install, be prepared to wait about 4 hours.
An XP install takes about a half hour.
Running it, well - it runs itself (especially for a file server, we're not talking about a fancy application server here).
If you take this view on any server, it WILL get owned eventually.
Slashdot Mirror
RTFA. The article says that the major players would be Linux and Windows, not the only players. Apple isn't interested in being a big player; they're interested in being a high margin high profit player.
If I were a resident of WA, I'd want to kick the politicians out first. They're the ones spending billions of dollars to construct a monorail that only runs a few miles. Where simple road projects span hundreds of million dollars. Where they build billion dollar stadium after stadium for sports teams -- the latest being building a frick'in race track. Taxes don't need to be increased to fix the education system in WA, the politicans just need to have their credit cards torn up.
... maybe I'll help do that in November...
Wait, I am a resident of WA
With the kind of forces involved in a large volcanic erruption, I would be very suprised if there wasn't a ton of advanced warning. A perfect example is Mt. St. Helens '80 erruption. The sucker was building up for quite some time before it blew.
Hell, we had over a weeks notice before this tiny event...
It wasn't a cloud. The wind blew the steam and ash in that general direction.
Then you either have the eyes of a hawk or something else was effecting the image quality of the images you were comparing.
And those cd based mp3 players have a ton of processing power (NOT), and getting ogg to play on those things isn't important at all...
However, you must first be attempting to leverate your monopoly to abuse that position. A media player has shipped with every version of Windows since the 3.x days. It was included before they were a monopoly. Their media player doesn't have a monopoly on the media player market after obtaining a monopoly in the OS market.
The only logical conclusion is that the mere act of bundling a media player with the operating system does not give them a monopoly on the media player market.
You certainly can't conclude that they're attempting that now when they havn't change their actions in 15 years...
There is one flaw with your arguement. Windows has ALWAYS shipped with a media player in one form or another (since the windows 3.x days). If their media player didn't obtain a monopoly during the period that Windows obtained a monopoly, shipping a media player with the OS is obviously not sufficient to monopolize the media player market. Therefore, the act of bundling a media player with an operating system cannot be construed as an attempt to monopolize the media player market.
I know a guy with a clown camera. I've seen the prints from it. For the sizes you were talking about, I can't tell a difference unless he breaks out a magnifying glass. I generally look at a picture, not parts of it through a magnifying glass.
For large prints there is definately a difference, but for the smaller sizes you were referring to I can't.
In my experience, people making statements like this don't consider a print "quality" unless they can look at the print with a magnifying glass and see detail you can't see with the naked eye...
where JPEG and TIFFS tend to be 8 bits per pixel.
JPEG/TIFF usually store 24 bits per pixel, or 8 bits per channel. TIFFs can store more than 8 bits per channel (I've used software which will read/save TIFFs with 16 bits per channel, or 48 bits per pixel).
The problem with saving a "normal" TIFF image is that you have to process the raw data and produce and RGB image from it, which means you take up roughly 3-4x (depending on the sensor if they consider the green data to be in two separate channels) as much space than you would if you just save the raw data.
Also, as mentioned already, settings such as white balance, tone, sharpness, color, and even exposure compensation can be applied after the shot was taken.
You can do this with a JPG or TIFF image - however your final result won't be as good.
Office 2003 and .NET Framework 1.1 were vulnerable, but if you had applied PREVIOUSLY AVAILABLE updates to either of those products, then, in fact, they weren't
.Net Framework 1.1 are vulnerable. Office 2003 SP1 and .Net Framework 1.1 SP1 are not (the service packs are your 'previously available update'). Microsoft refers to service pack levels when specifying which products are and are not vulnerable. Lack of a sp level indicates a product without a service pack applied.
Office 2003 and
Raw images from the Nikon D70 hover around 2-6mb. As the images are compressed (pseudo losslessly; Nikon compresses the highlight information to 10bits), the size varies.
If you do any post processing, raw + 16bpc imaging tools are the way to go.
Unfortunately, "get it right the first time" isn't possible because you don't have a laptop sitting next to you to examine the image in every fine detail.
The biggest advantage digital cameras give you over film is the flexability to NOT get it right the first time. Aside from the power to take a large number of shots to experiment with ideas you wouldn't otherwise give the time of day, it also allows you to fix things you didn't notice when you did take the image. If you just want to shoot once and hope it turns out the way you imagined, don't bother getting a dslr.
A lot can be done to process an image after capturing it, and the extra few bits of information make a huge difference in the final quality of the image. Add into the equation a sharper image and better color (jpgs seem to 'compress' the red channel more than others...). Not to mention the advantage it gives you if you decide to work in a colorspace other than sRGB (ie: more accurate color when transforming to the printer's colorspace).
Yeah. Most of us refuse to consider the possibility because it's utterly stupid.
...
I can imagine that similar things were said when it was suggested that the Earth wasn't at the center of the universe and that everything didn't revolve around it.
Disprove his evidence instead of mocking it as "stupid" and inconceivable.
I've never seen lag like that caused by an LCD and I can't imagine how the electronics could create that effect.
The demonstration video showed the LCD off by 1 or 2 frames. Nobody would notice that kind of delay unless the LCD were placed next to a CRT in a multi-mon configuration. And hey, guess what this guy did?
At 30fps, that delay would be 33 to 66ms. The LCD switching speeds in monitors these days seem to range between 16 to 20ms. So, question is, can you realistically introduce another 13 to 50ms? Don't forget to include the A2D converters and circuitry designed to compensate for mismatching the refresh rate from the preferred rate...
Like another post already said, the LCD would need a screen data buffer of several megabytes and it doesn't have one.
You don't need a large data buffer to see that kind of effect, you just need a long enough data pipeline.
The dude has a video of multimon setup demonstrating the 'lag'. If it were mouse drivers both screens would draw at the same rate.
...
I'm going to presume that he was smart enough to test the same setup with a CRT to see if the problem persists to rule out the video card/drivers, but you never know
This isn't about rating machines for sale, it's about making it easy for the home user to determine if a piece of software will run on the machine they already own.
...
It isn't meant for people like you, because you already know what all of the terms are and how they relate to each other. Joe Schmoe who buys his computer at Walmart doesn't know the difference between RAM and HD space, let alone that a 2ghz P4 is way slower than a 2ghz Athlon
We have exactly that. The problem is that the average consumer doesn't know what any of those specs represent, has no idea what is inside their computer, and really doesn't know if their computer can really run the software they are buying (they just assume it will).
... they're usually on the bottom of the box in a 4pt font...
Hell, I have problems reading through the system requirements
While it would be technically possible to overcome these problems by upping the bandwidth allocated to each individual station
The other way to do it would be to have a few additional tuners recording the stream from the next and previous channels so you have a stream ready to use when you flip through channels... This would be an optimal way to use the extra tuners used for pip built into the fancy tv's that allow like 2 or 3 pip displays on screen at once.
Prove it instead of FUDing about it.
The OS doesn't come to a screeching halt. It continues working just fine. The poorly programmed application starts behaving badly, essentially making it useless. Instead of telling people how to restart the application in question, they apparently found it easier to tell people to hit the reset button instead.
Then you break backwards compatibility with all of the existing applications that call that API. Compiled code doesn't tend to work nicely when it expects 4 bytes on the stack and gets 8 bytes instead.
If your code can't deal with a rollover condition, you should be calling GetSystemTime instead. Typically, the reason why people call GetTickCount instead of GetSystemTime is generally due to lazyness (it's harder to "sort" the system time structure than a dword).
It doesn't reboot immediately -- you can see the machine bluescreen; it remains bluescreened until it writes out a minidump of the operating system state. It also adds an entry into the eventlog to record the crash. THEN it reboots.
Personally, it seems to be really stupid to leave a machine (that may or may not be responsible for some critical service) in a crashed state when it can be rebooted automatically.
The only time I've ever gotten blue screens on my machine was when I was playing around with overclocking my machine. Backed the timings off to spec and haven't had one single crash since.
Once I had finished the install, the online update installed a couple of security patches that downloaded in about 10-20 minutes over my modem link.
... yeah, for a server that is in production they suck, and that is a valid complaint, but setting up the machine initially? It isn't like XP takes 15 minutes to boot ...
... if I really wanted to, I could spend the time figuring out how to get stuff done right (once upon a time I had an m68k version of the kernel running on an Atari TT030). Back when I was in college, I had all the time in the world fiddling and twiddling with things. Problem is, I don't have that kind of time anymore -- I just want to use the darn thing.
This was my biggest problem with the install actually. It presented a huge list of locations to download patches from. The first five I selected (at random, because duh, which one is a good one to pick?) didn't work. There were also 2 or 3 poorly worded checkboxes, each which was ambiguous to the point where I wasn't sure if selecting or not selecting the checkbox would cause patches to actually be downloaded and installed. I decided leaving them alone would be the safest.
After that, I click whatever button there was that tells the thing to start, and proceed to spend the next 2 hours (via cable modem) waiting for patches to download. I eventually gave up and went to bed -- the next morning I discover that an error occured during part of the process and it stopped (not too long after I left it alone for the night, as the progress bar hadn't moved that far). What the error was, I couldn't tell you. What I was supposed to do about it, I couldn't tell you either -- the only rational options were a. reinstall from scratch and try again or b. continue with the install and hope that some other process would update it properly next time or that I'd figure out how to do it myself. The "error" sure as hell didn't suggest anything on the issue.
Don't even get me started about the mess that was setting up KDE or X or whatever the hell it did afterwards...
With XP, the install took a similar amount of time, but I additionally had to install several other applications that took about 10-20 minutes each to achieve the same level of functionality.
Yeah, net "install" time with that factored in (ie: time to install applications) is probably much closer, though I can't remember the last time it took me 10-20 minutes to install an application aside from Visual Studio.
and I had to reboot twice in order to install everything (the Linux updates did not require a reboot).
I don't get what the obcession over reboots is
I'm not an idiot
installing linux on hardware that's on the HCL is trivial and takes half the time of Windows
... if you choose a minimal install, it takes very little time to install -- however, you have to take the time and frigging deselect everything that is preselected for you, and then go through the million dialogs saying "xyz depends on this library" and turn a bunch of things back on you way in the negative as far as install time goes. If you choose a default install, be prepared to wait about 4 hours.
You are ON CRACK if you think that installing Linux is trivial. Given the inconsistent, poorly worded, in some cases confusing text presented during Linux distro installs I'll take the XP cd any day of the week.
Same comment applies to install time
An XP install takes about a half hour.
Running it, well - it runs itself (especially for a file server, we're not talking about a fancy application server here).
If you take this view on any server, it WILL get owned eventually.