you are right, but I wanted to continue along the same lines as the person. Calling windows a junker and macos a sports care is quite silly. They are more or less in the same class in this context. That's all I was trying to say. At the moment, I cant think of a better analogy that says "this is a trivial change, and not a replacement of a good amount of the inner workings".
That is such a bad analogy. This is more like two cars of similar class, where one is sold with the windows down, the other up. Of course the one with the windows up can go faster, but any moron can roll up the windows.
As the article stated, bees are very important for polination on many species of plants. In english: The bees help the plants have sex.
Severly reduce the bees, and you have less seeds. Less seeds means less plants. Oh, and most fruits are just elaborate seed casings, so fewer bees -> fewer seeds -> lower fruit output of such plants -> lower crop.
oh, addendum: I don't know if there was any fade effects by default on the Mac or not, so even my mentioned experience may contain bias.
I still plan to buy a Mac when I get the money, it's good to have a bit of everything to play with, and I hear the minis doa great job of dual booting Aero...
I've no qualms with comparing the defaults, I'm just saying, I'd like to know the setup of the comparison, and it should be made note that "These are the defaults", and "With trivial change, these are the results".
The reason I mention this, is that the UI on my Windows XP desktop at home, a AthlonXP 2500+ with 1GB of memory, seems faster than the UIs of the Mac Minis at the store with Core2 Duos and 1 GB of memory. With that setup, they should vastly outperform my machine.
And all that with just a couple of clicks of tweaking.
That, and also, what kind of options did they have turned on?
I turned of menu fade in any system I'm on, be it Windows XP, BSD -w- KDE, whatever.
All of them display menus virtually instantly like that. Depending on which (KDE, Gnome, Windows), you start to notice slowdowns at various cuttoffs, KDE and Windows tend to slow down faster with decreased memory than CPU, Gnome with decreased CPU more than memory.
That being said, if Windows has a menu fading effect turned on and OS X does not, then there is a lot of bias right there. Also, if XP's fade is set to a shorter time, that's bias too.
Also, there's system information: Did they compare systems with identical or close to identical hardware? Did they compare systems with identical costs? Ex:
Both systems had e6600 Core 2 Duo CPUs with 2GB of DDR2 800 and a 200GB 7200 RPM SATA 3.0GB/s drive, or
Both systems were $1800 from the leading manufacturer (say Apple and Dell for OS X and Vista/XP respectively)
I guess what I'm getting at is I'd really rather see the methods of the experiment rather than just the conclusions. It's not that I find it all that hard to believe (well, the mouse precision seems a little odd, I've never had an issue with the mouse selecting any pixel except that which I told it to click, even on precision stuff where actual pixel mattered - I can believe the menu performance potentially).
I didn't see an actual link to the report in the article, is it pay to read, or did I just miss it?
I wouldn't necessarily call it a free ride. They would be leasing the lines, meaning they would be paying for the use.
I can see two issues to this:
(1) DT Owns the lines: I don't see why they'd be so upset, they can charge what they want can't they? (2) The Government owns the lines, DT just built them for the government. Well, DT should have charged more shouldn't htey? Guess they bit themselves in the ass on that one (if it's the case).
Ahh, but now we are getting into security and out of stability.
I'm sure that the RN would have a lot of third party security apps surrounding their warships software, as well as non-essential services turned off.
I'd like to think they'd keep it locked-down enough (and the users educated enough) to block users from getting other garbage onto them, but who knows?
Still, as I said in another post. I'd rather see it running BSD rather than Windows.
Stability, along with ease of use are non-negotiable for me. The only reason my more recent systems haven't had multimonth uptimes is because of Windows updates. A planned reboot is not the same as an instability, so it works for me.
That and I avoid three games one Windows. One of them I play in WINE on my BSD box.
maybe I was lucky and didn't have a lot of COM stuff, which is the majority of what that document referenced?
I don't know, I just have not had the issue since 9x. A lot of it is, I think, because many programs have their own local variants of anything they use that tends to conflict with other apps, in their own directory. It's certainly more wasteful than the *nix mindset in terms of space, but space it cheap.
Typically in windows I install an app, it just works, regardless of what else I install. In the rare cases that doesn't happen, it simply asks me to uninstall the old version, and viola, it works. I don't think I've ever seen a case of a different application causing a problem.
With apt and yum, I've often seen Package A requires Library X version Y Package B requiers Library X version Z
and they would *NOT* install simultaniously without fiddling and telling the updaters to ignore dependancies, etc. Or, alternatively, Package C requires Library W. Cannot find Libarary W in repositories. And of course various searches, including several online repositories, leads me to dead ends.
I have not seen those things in Windows, even with hundreds of program installs. Not since the 9x days at any rate.
Yes, a software bug, such as the driver. I was just saying that stress tests wont find everything.
I've never had an easy time troublshooting Linux myself. One of the reasons I stick to FreeBSD and Windows. Again it's my own experience. I understand your experiences almost certainly differ, it comes to different mindsets and approches to debugging, and not one of us being right, and the other wrong, so please, lets skip that argument (if you weren't going to start it, I appologize, but I've goteen it enough here).
I've had hardware die on a Windows machine without crashing it a lot.
Windows would have one definet disadvantage of *NIX though. Because of the ways you can run various *NIX systems, if something knowcked out the system disk, you could possibly still get a few seconds to minutes of run time out of the system (and if it were specifically planned for, even hours). Windows would be gone in miliseconds.
You do have a point there. And I agree, I'd rather see something than Windows on a military ship (I'd vote BSD myself). I was just saying that Windows may not be as bad as some people would think, especially in these non-DOS days.
I've found library hell to be worse on Linux, even with Ubuntu, in my experience than in Windows. Still, Ubuntu's package manager in conjunction with they way they handle their repositories the is leaps and bounds ahead of some of the competition (especially RHL/YUM). Registry, I'll grant you that is a magnet for problem-causing garbage.
As for (B) and stress tests, The trick isn't so much to put a high load in all the time, but to trigger the wrong event in the wrong state, stress tests can easily miss this one.
I've done hundreds of system installs on similar machines with the same disks, and not had the problem you mentioned. *shrug* Everyone has had their own experiences.
I'm just stating my experience with them. As for OO and Java, I have installed them and worked on them with my own machines.
And if you bothered to read, I never complained about OO, it was Star Office PRE-OPEN SOURCE.
As for the server, I knew there were several variants, all sparc, some pre-2000, some not, sorry I can't tell you more than that. I know one of the admins handled several sets of *nix boxes, and only the suns had problems, and in that situation, they were the lowest yeild.
Maybe I had bad experiences, maybe I got the worst end of the lot, but they were my experiences, and, honestly, with those experiences, would you trust/your/ valuable time, data and effort to such a company?
Sorry that my oppinions and experiences differ from yours. Sorry I'm not a lemming, but I'm not saying others shouldn't use this, I just said I wanted something else.
Regarding the crashing though, I found that on my Windows system, most crashes can be attributed to either
(A) Bad hardware (B) Bad drivers - usually the graphics driver.
The more complicated 3D stuff an app does, especially a game, the more problematic it is in terms of stability, though this is not always the case - many professional apps put a lot more time into getting aroudn these bugs.
On one machine I had, regardless of the OS, if I had high network IO with either high CPU use or high 3D use, it crashed. Changed the mobo, problem went away.
On another, it had not only one of the worst SATA chips out there, but probably one of the worst implementations of said chip. Linux and FreeBSD solved the stability issue by not installing on anything except IDE drives, Windows on the other hand installed, but had issues. A new SATA controller card fixed that.
Yes Windows has issues. But in my old Windows 2000 box, with a Tyan Trinity S1598 based box, K6-III 450 and 512MB of memory, I was regularly getting multi-month uptimes. And I even gamed a bit, though not much.
The point is, as you stated, you/can/ make Windows stable, it just takes a bit of effort because
(1) Driver quality is more relevant - I don't know the details but a bad driver is less likely to crash the whole system, in my experience, in FreeBSD or Linux. (2) Windows is more likely to load up on bad hardware. It's also more vulnerable to issues related to bad hardware.
Note: this is just for 2000 and later (really, in my experience XP is a downgrade on stability, and I can't say much on Vista, though mileage may vary). 9x variants of Windows were crashmonsters.
Notice I said *PRE* open soucring, and Star Office? I'm perfectly happy with Open Office, except for the rare few occasions it has had trouble with MS Word docs, and I can't blame them for the lack of MS documentation. But Star Office, the version before being open sourced wouldn't last 20 minutes without a crash in Windows or Linux for me.
As for Sun, maybe I just had bad luck, but I had two different situations where I had Solaris servers (various variants of the Sparc processor around 2000-2004, either multi-dev - web, java, C, and one was a mail server) that crashed daily, but the True64 servers didn't crash, and the Windows server normally got at least a week of uptime.
NOTE: This quote is not the previous authors comment, but a modification.
Normally I'd agree with you. But if you read both articles, you realize that his intentions may be a bit more honorable. The Win32 article is the exact same layout, but with pieces of content and conclusion changed. Maturing opinions usually result in some discussion of why one has changed their mind (even if it's only mentioned in passing) and/or a deep explanation of what caused their mind to change. This smells more like he was embarrased about his old oppinions.
Of course, it could be that the author is simply not comfortable with writing. He could be looking to make a quick buck by taking a simple forum post of his and modifying it to reflect his current opinion. It's worth giving him the benefit of the doubt on, but I am certainly suspicious. The content of this quote is exactly the same as the content of the parent like the content of the two articles are exactly the same.
There's a lot of different information in them, they just follow a very similar, and possibly copy and pasted format. Normally I would agree that a discussion of the change of veiw would be appropraite, and actually I still do agree, but your reply was a bit harsh. The two articles to me combine to say:
(1) pthreads are *MUCH* easier to learn for a novice programmer, and can get most tasks done just fine. (2) Win32 threads are *MUCH* harder to learn [very believable after looking at some of the Windows API], but have a bit more functionality and flexibility.
It may also relate to a change in the Win32 thread API, but I doubt that would have changed so significantly.
Or you could be right, he could be a jerk out for a buck, but I doubt it's as clear-cut as your post suggests.
Slashdot Mirror
you are right, but I wanted to continue along the same lines as the person. Calling windows a junker and macos a sports care is quite silly. They are more or less in the same class in this context. That's all I was trying to say. At the moment, I cant think of a better analogy that says "this is a trivial change, and not a replacement of a good amount of the inner workings".
That is such a bad analogy. This is more like two cars of similar class, where one is sold with the windows down, the other up. Of course the one with the windows up can go faster, but any moron can roll up the windows.
definetly!
please tell me that's a joke.
As the article stated, bees are very important for polination on many species of plants. In english: The bees help the plants have sex.
Severly reduce the bees, and you have less seeds. Less seeds means less plants. Oh, and most fruits are just elaborate seed casings, so fewer bees -> fewer seeds -> lower fruit output of such plants -> lower crop.
oh, addendum: I don't know if there was any fade effects by default on the Mac or not, so even my mentioned experience may contain bias.
I still plan to buy a Mac when I get the money, it's good to have a bit of everything to play with, and I hear the minis doa great job of dual booting Aero...
I've no qualms with comparing the defaults, I'm just saying, I'd like to know the setup of the comparison, and it should be made note that "These are the defaults", and "With trivial change, these are the results".
The reason I mention this, is that the UI on my Windows XP desktop at home, a AthlonXP 2500+ with 1GB of memory, seems faster than the UIs of the Mac Minis at the store with Core2 Duos and 1 GB of memory. With that setup, they should vastly outperform my machine.
And all that with just a couple of clicks of tweaking.
That, and also, what kind of options did they have turned on?
I turned of menu fade in any system I'm on, be it Windows XP, BSD -w- KDE, whatever.
All of them display menus virtually instantly like that. Depending on which (KDE, Gnome, Windows), you start to notice slowdowns at various cuttoffs, KDE and Windows tend to slow down faster with decreased memory than CPU, Gnome with decreased CPU more than memory.
That being said, if Windows has a menu fading effect turned on and OS X does not, then there is a lot of bias right there. Also, if XP's fade is set to a shorter time, that's bias too.
Also, there's system information:
Did they compare systems with identical or close to identical hardware?
Did they compare systems with identical costs?
Ex:
Both systems had e6600 Core 2 Duo CPUs with 2GB of DDR2 800 and a 200GB 7200 RPM SATA 3.0GB/s drive,
or
Both systems were $1800 from the leading manufacturer (say Apple and Dell for OS X and Vista/XP respectively)
I guess what I'm getting at is I'd really rather see the methods of the experiment rather than just the conclusions. It's not that I find it all that hard to believe (well, the mouse precision seems a little odd, I've never had an issue with the mouse selecting any pixel except that which I told it to click, even on precision stuff where actual pixel mattered - I can believe the menu performance potentially).
I didn't see an actual link to the report in the article, is it pay to read, or did I just miss it?
I wouldn't necessarily call it a free ride. They would be leasing the lines, meaning they would be paying for the use.
I can see two issues to this:
(1) DT Owns the lines: I don't see why they'd be so upset, they can charge what they want can't they?
(2) The Government owns the lines, DT just built them for the government. Well, DT should have charged more shouldn't htey? Guess they bit themselves in the ass on that one (if it's the case).
I'm not sure, but the article seems to place him more as an independant (or competative) critic, rather than a part of the program.
Yeah, that kind of treatment seems like it'll cause more problems than it'll help.
I like the comments from Tao in there. He seems to have a better idea on how to handle the situation, I hope he gets a chance to try his way.
In plain english: to get them off the internet, we gotta get them laid.
Or, you can use it as a coaster for your Guinness!
Brilliant!
I thought you were going to say "I for one welcome our minimilist phone overlords."
Now I can't get the Queen song Barcelona out of my head (I heard it yesterday, then you make this reference)
Thanks.
Oh, and good point to.
why not offer a stripped down version?
The iMac/eMac of the iPhones!
The iPhone mini!
Ahh, but now we are getting into security and out of stability.
I'm sure that the RN would have a lot of third party security apps surrounding their warships software, as well as non-essential services turned off.
I'd like to think they'd keep it locked-down enough (and the users educated enough) to block users from getting other garbage onto them, but who knows?
Still, as I said in another post. I'd rather see it running BSD rather than Windows.
Stability, along with ease of use are non-negotiable for me. The only reason my more recent systems haven't had multimonth uptimes is because of Windows updates. A planned reboot is not the same as an instability, so it works for me.
That and I avoid three games one Windows. One of them I play in WINE on my BSD box.
maybe I was lucky and didn't have a lot of COM stuff, which is the majority of what that document referenced?
I don't know, I just have not had the issue since 9x. A lot of it is, I think, because many programs have their own local variants of anything they use that tends to conflict with other apps, in their own directory. It's certainly more wasteful than the *nix mindset in terms of space, but space it cheap.
Typically in windows I install an app, it just works, regardless of what else I install. In the rare cases that doesn't happen, it simply asks me to uninstall the old version, and viola, it works. I don't think I've ever seen a case of a different application causing a problem.
With apt and yum, I've often seen
Package A requires Library X version Y
Package B requiers Library X version Z
and they would *NOT* install simultaniously without fiddling and telling the updaters to ignore dependancies, etc.
Or, alternatively, Package C requires Library W. Cannot find Libarary W in repositories. And of course various searches, including several online repositories, leads me to dead ends.
I have not seen those things in Windows, even with hundreds of program installs. Not since the 9x days at any rate.
Yes, a software bug, such as the driver. I was just saying that stress tests wont find everything.
I've never had an easy time troublshooting Linux myself. One of the reasons I stick to FreeBSD and Windows. Again it's my own experience. I understand your experiences almost certainly differ, it comes to different mindsets and approches to debugging, and not one of us being right, and the other wrong, so please, lets skip that argument (if you weren't going to start it, I appologize, but I've goteen it enough here).
I've had hardware die on a Windows machine without crashing it a lot.
Windows would have one definet disadvantage of *NIX though. Because of the ways you can run various *NIX systems, if something knowcked out the system disk, you could possibly still get a few seconds to minutes of run time out of the system (and if it were specifically planned for, even hours). Windows would be gone in miliseconds.
You do have a point there. And I agree, I'd rather see something than Windows on a military ship (I'd vote BSD myself). I was just saying that Windows may not be as bad as some people would think, especially in these non-DOS days.
I've found library hell to be worse on Linux, even with Ubuntu, in my experience than in Windows. Still, Ubuntu's package manager in conjunction with they way they handle their repositories the is leaps and bounds ahead of some of the competition (especially RHL/YUM). Registry, I'll grant you that is a magnet for problem-causing garbage.
As for (B) and stress tests, The trick isn't so much to put a high load in all the time, but to trigger the wrong event in the wrong state, stress tests can easily miss this one.
I've done hundreds of system installs on similar machines with the same disks, and not had the problem you mentioned. *shrug* Everyone has had their own experiences.
I'm just stating my experience with them. As for OO and Java, I have installed them and worked on them with my own machines.
/your/ valuable time, data and effort to such a company?
And if you bothered to read, I never complained about OO, it was Star Office PRE-OPEN SOURCE.
As for the server, I knew there were several variants, all sparc, some pre-2000, some not, sorry I can't tell you more than that. I know one of the admins handled several sets of *nix boxes, and only the suns had problems, and in that situation, they were the lowest yeild.
Maybe I had bad experiences, maybe I got the worst end of the lot, but they were my experiences, and, honestly, with those experiences, would you trust
Sorry that my oppinions and experiences differ from yours. Sorry I'm not a lemming, but I'm not saying others shouldn't use this, I just said I wanted something else.
Regarding the crashing though, I found that on my Windows system, most crashes can be attributed to either
/can/ make Windows stable, it just takes a bit of effort because
(A) Bad hardware
(B) Bad drivers - usually the graphics driver.
The more complicated 3D stuff an app does, especially a game, the more problematic it is in terms of stability, though this is not always the case - many professional apps put a lot more time into getting aroudn these bugs.
On one machine I had, regardless of the OS, if I had high network IO with either high CPU use or high 3D use, it crashed. Changed the mobo, problem went away.
On another, it had not only one of the worst SATA chips out there, but probably one of the worst implementations of said chip. Linux and FreeBSD solved the stability issue by not installing on anything except IDE drives, Windows on the other hand installed, but had issues. A new SATA controller card fixed that.
Yes Windows has issues. But in my old Windows 2000 box, with a Tyan Trinity S1598 based box, K6-III 450 and 512MB of memory, I was regularly getting multi-month uptimes. And I even gamed a bit, though not much.
The point is, as you stated, you
(1) Driver quality is more relevant - I don't know the details but a bad driver is less likely to crash the whole system, in my experience, in FreeBSD or Linux.
(2) Windows is more likely to load up on bad hardware. It's also more vulnerable to issues related to bad hardware.
Note: this is just for 2000 and later (really, in my experience XP is a downgrade on stability, and I can't say much on Vista, though mileage may vary). 9x variants of Windows were crashmonsters.
note: I wasn't the admin of any of those servers, I left that to the professionals in the various places that they were located.
Wanna make any more innacurate assumptions about me and the situation?
Notice I said *PRE* open soucring, and Star Office? I'm perfectly happy with Open Office, except for the rare few occasions it has had trouble with MS Word docs, and I can't blame them for the lack of MS documentation. But Star Office, the version before being open sourced wouldn't last 20 minutes without a crash in Windows or Linux for me.
As for Sun, maybe I just had bad luck, but I had two different situations where I had Solaris servers (various variants of the Sparc processor around 2000-2004, either multi-dev - web, java, C, and one was a mail server) that crashed daily, but the True64 servers didn't crash, and the Windows server normally got at least a week of uptime.
Of course, it could be that the author is simply not comfortable with writing. He could be looking to make a quick buck by taking a simple forum post of his and modifying it to reflect his current opinion. It's worth giving him the benefit of the doubt on, but I am certainly suspicious. The content of this quote is exactly the same as the content of the parent like the content of the two articles are exactly the same.
There's a lot of different information in them, they just follow a very similar, and possibly copy and pasted format. Normally I would agree that a discussion of the change of veiw would be appropraite, and actually I still do agree, but your reply was a bit harsh. The two articles to me combine to say:
(1) pthreads are *MUCH* easier to learn for a novice programmer, and can get most tasks done just fine.
(2) Win32 threads are *MUCH* harder to learn [very believable after looking at some of the Windows API], but have a bit more functionality and flexibility.
It may also relate to a change in the Win32 thread API, but I doubt that would have changed so significantly.
Or you could be right, he could be a jerk out for a buck, but I doubt it's as clear-cut as your post suggests.