I'm a full day Ubuntu user (yet with 7.10). When there is any Ubuntu "performance comparison" the only single thing that comes to my mind is the sluggishness of Gnome/Compiz after some hours of continued work (even in my Core2-duo laptop.) Even that is not necessarily related to Ubuntu.
I think for most users the OS performance is a non-issue. It's the applications that matter. Of course, on M$, its more about the stupid background antivirus and other "utilities".
Nah..... just go beyond that silly traditional dichotomy by consistently applying eXtreme programming, so you will never need to know if you're reutilizing or recoding... you're just eXtreme programming your never ending requirements.
I agree, it was slow. But sometimes a slow computer forces you to think in better ways to acomplish your tasks, and if you're just learning to program, this can be a good habit (of course, I don't think the 64 is the best platform to learn... got my point)
Sadly, today there is an abuse of "premature optimization is the source of all evils", and young programmers just expect the compiler and the hardware to resolve every performance issue.... well, really they apparently do ignore there can exist performance issues.
For professional developers it also may provide some benefits; for example, sometimes I think the Gnome/gtk/etc developers should be given just 486 machines or at most Pentium II machines to develop and test all their code; I'm sure they could eventually get a decent speed on these systems (they're really smart) and would be a wonder for most people running current Core-2 and the like.
We're used to provide the coders with the top hardware (or the coders auto-provide it) as if that would provide better/faster code... the opposite is the truth.
If humans could live for a dozen of million of years, maybe it could be normal to see 1/3 of a big subset of the species disappearing because of natural selection as you point, but for our minuscule time lapse it is a total artificial catastrophe.
>> For user-friendly answers, the *BSD documentation is very extensive (try the FreeBSD handbook,...
Sadly these days people do not read documentation, and just expect there is somebody out in the forums that will respond something, not necessarily correct, just in order to make the system work (and no, it doesn't matter how it actually works).
So responding to GP, I assume that openBSD is actually targeted for another world.
But when the technology is just starting to be probed (as this case), it is more susceptible to break things. Following your example, DOS applications do not run in modern Windows versions.
Now, despite the API/ABI specs (as Win32), a lot (most?) of the applications designed for Win 3.1, Win 95, Win 98 simply do not run in XP/Vista/2003/etc without several weird patches or difficult to find DLL's/OCX's/etc. Even if the substrate is Win32, in the field it doesn't work out of the box.
The article discusses just that scenario where the supposedly compatible OS is forcibly upgraded and you need developers around to "patch" the installation, or in the best case just to do a recompilation.
I don't understand. Why just don't detonate the "refrigerator" with a bomb while in path to the earth so the remaining parts disintegrate as normal meteorites? BTW, for bigger things (like nuclear trash) how difficult/costly (in energy) would be to send that things to the sun?
That's the main point in the article: since MS (as others) is always compelled to evolve to remain competitive, they will eventually force you to upgrade the applications: it is not always easy (or profitable) to maintain backward compatibility.
It is like an enterprise where the sysadmin has the full power to eventually upgrade the OS in all the servers, maybe with something *theoretically* back-compatible, but you know what that means...
Contrast with traditional non-cloud, where you may eventually find a DOS-box if that is what your application does require, and for whatever reason (there are many) you can't upgrade/rewrite it.
>>I don't know where you work, but unstable servers are usually a result of poor planning by system architects, insufficient funding, or inexperienced sysadmins
Well, just to add some data, I used to work in telco systems where we have to support several heterogeneous software from different vendors that "certify" its product for several Unix configurations (and databases), so supposedly they do some of the planning ahead (note that they also have to develop several country-specific -i.e. mostly unplanned- customizations.) The rest of the decisions comes from our "architecture staff" but there are also some key "regional corporate decisions" on the brands. Most of the time the difficult problems were passed to the Unix vendors (they usually came with customer-specific-patches), so we also shared the sysadmin duties.
Sadly in that environment it is difficult to do all the logical things you say, and you end just testing the configurations in a rush some weeks before passing to production. And before you get the desired % of uptime, you get a new generation of software/hardware that you *MUST* apply because of the fast moving "business requirements" (you know, the sector was growing in the last years, as mobile technology is being created all the time.)
Interestingly, the more stable equipment was our internet-related RedHat machines (maybe since about the.com-crash there was not many changes in that front, at least for us.)
I also worked as Unix sysadmin for several years (but no longer... I love to sleep all night long) and from my experience:
1) Most "big datacenters" have several key servers that are really unstable despite being Unix(tm), mostly because of evil combinations of HW/Applications/OS (patches and more patches from Oracle, NUMA configurations, etc)... as happens with any Linux. 2) Most servers in datacenters are 99% idle, except when silly programmers try to execute infinite pooling loops or that sort of things. There is a myth (now banishing) that you need a real Unix of >100K$ to do the real work; think of the price of Sun's.
So apart from their trash PC hardware, I believe those kids with LAMP systems do really know a bit on stability and heavy load (think of/.)
Interesting link, but the arguments are too similar to the classical die-hard C programmers that never did learn OO principles, kind of:
"you can create objects with structures and function pointers" "several c-toolkits are already object oriented -for example, X-intrinsics, so we don't need this C++ crap".
Also, note that most (if not all) of the rant about the silly OO-constructs in PHP5 apply to Java... so the conclusion is that Perl is better than Java in OO support.
I hate the idea of a proliferation of AV software for Linux... people proposes that, because they assume that is a normal thing to live with a platform too vulnerable like MS... From install XP and Vista do "alert" that there is a "security problem" when there is no AV, so they assume from start that the OS or the apps are not (and can not be) correctly written at all.
So bad that people assumes that living with parasitic AV is normal/healthy; is like assuming that all people must carry guns every time.
But how many of those millions use their time to just untar the source code?... and to understand the source code?... and to fix the source code?
I think the advantage is that the (few?) FOSS hackers are not too compromised to a big business so they 1) can improve the security via best code quality without managers stopping the work because of profitability/marketing timelines, and 2) they do not need to hide or lie about the bad security issues.
>> trees tend to grow up unless they tend to grow down or sideways.
Of course you can expect a dramatic reduction in source code size as the 2.8 finally introduces C++, the full OO paradigm, several Go4 official design patterns, and a bit of eXtreme Programming in order to recruit more young programmers.
>>This destroys Microsoft's claim that their intimate knowledge of the OS that runs IE will increase performance.
After the criticisms about the "secret Windows APIs" Wikipedia the last thing M$ will do is to proclaim they have some exclusive "intimate knowledge". Of course, being the creator they should know the product better than most people.
Slashdot Mirror
I'm a full day Ubuntu user (yet with 7.10). When there is any Ubuntu "performance comparison" the only single thing that comes to my mind is the sluggishness of Gnome/Compiz after some hours of continued work (even in my Core2-duo laptop.) Even that is not necessarily related to Ubuntu.
I think for most users the OS performance is a non-issue. It's the applications that matter. Of course, on M$, its more about the stupid background antivirus and other "utilities".
>> If it takes more than one day to compile it's too big to be elegant anyway.
Or the build system is no elegant (poor Makefiles, or the always brain-dead autoconf.)
Nah..... just go beyond that silly traditional dichotomy by consistently applying eXtreme programming, so you will never need to know if you're reutilizing or recoding... you're just eXtreme programming your never ending requirements.
I agree, it was slow. But sometimes a slow computer forces you to think in better ways to acomplish your tasks, and if you're just learning to program, this can be a good habit (of course, I don't think the 64 is the best platform to learn... got my point)
Sadly, today there is an abuse of "premature optimization is the source of all evils", and young programmers just expect the compiler and the hardware to resolve every performance issue.... well, really they apparently do ignore there can exist performance issues.
For professional developers it also may provide some benefits; for example, sometimes I think the Gnome/gtk/etc developers should be given just 486 machines or at most Pentium II machines to develop and test all their code; I'm sure they could eventually get a decent speed on these systems (they're really smart) and would be a wonder for most people running current Core-2 and the like.
We're used to provide the coders with the top hardware (or the coders auto-provide it) as if that would provide better/faster code... the opposite is the truth.
Now you will get a ton of Ubuntu backgrounds....
Now I'm really angry 'cause I can't mod you. Those 5 f**ing points expired yesterday!
If humans could live for a dozen of million of years, maybe it could be normal to see 1/3 of a big subset of the species disappearing because of natural selection as you point, but for our minuscule time lapse it is a total artificial catastrophe.
Ok, maybe that is about geek alarms. But for most people, the best is play up to the burglar fears, for example put a BIG sticker that says:
"BEWARE - DOBERMAN TRAINING OFFICE".
One that normally makes "BOOOOMMMMMMMMM" in earth.
>> For user-friendly answers, the *BSD documentation is very extensive (try the FreeBSD handbook,...
Sadly these days people do not read documentation, and just expect there is somebody out in the forums that will respond something, not necessarily correct, just in order to make the system work (and no, it doesn't matter how it actually works).
So responding to GP, I assume that openBSD is actually targeted for another world.
But when the technology is just starting to be probed (as this case), it is more susceptible to break things. Following your example, DOS applications do not run in modern Windows versions.
Now, despite the API/ABI specs (as Win32), a lot (most?) of the applications designed for Win 3.1, Win 95, Win 98 simply do not run in XP/Vista/2003/etc without several weird patches or difficult to find DLL's/OCX's/etc. Even if the substrate is Win32, in the field it doesn't work out of the box.
The article discusses just that scenario where the supposedly compatible OS is forcibly upgraded and you need developers around to "patch" the installation, or in the best case just to do a recompilation.
I don't understand. Why just don't detonate the "refrigerator" with a bomb while in path to the earth so the remaining parts disintegrate as normal meteorites? BTW, for bigger things (like nuclear trash) how difficult/costly (in energy) would be to send that things to the sun?
That's the main point in the article: since MS (as others) is always compelled to evolve to remain competitive, they will eventually force you to upgrade the applications: it is not always easy (or profitable) to maintain backward compatibility.
It is like an enterprise where the sysadmin has the full power to eventually upgrade the OS in all the servers, maybe with something *theoretically* back-compatible, but you know what that means...
Contrast with traditional non-cloud, where you may eventually find a DOS-box if that is what your application does require, and for whatever reason (there are many) you can't upgrade/rewrite it.
Sorry, it has Ubuntu inside.
>>I don't know where you work, but unstable servers are usually a result of poor planning by system architects, insufficient funding, or inexperienced sysadmins
Well, just to add some data, I used to work in telco systems where we have to support several heterogeneous software from different vendors that "certify" its product for several Unix configurations (and databases), so supposedly they do some of the planning ahead (note that they also have to develop several country-specific -i.e. mostly unplanned- customizations.) The rest of the decisions comes from our "architecture staff" but there are also some key "regional corporate decisions" on the brands. Most of the time the difficult problems were passed to the Unix vendors (they usually came with customer-specific-patches), so we also shared the sysadmin duties.
Sadly in that environment it is difficult to do all the logical things you say, and you end just testing the configurations in a rush some weeks before passing to production. And before you get the desired % of uptime, you get a new generation of software/hardware that you *MUST* apply because of the fast moving "business requirements" (you know, the sector was growing in the last years, as mobile technology is being created all the time.)
Interestingly, the more stable equipment was our internet-related RedHat machines (maybe since about the .com-crash there was not many changes in that front, at least for us.)
I also worked as Unix sysadmin for several years (but no longer... I love to sleep all night long) and from my experience:
1) Most "big datacenters" have several key servers that are really unstable despite being Unix(tm), mostly because of evil combinations of HW/Applications/OS (patches and more patches from Oracle, NUMA configurations, etc)... as happens with any Linux.
2) Most servers in datacenters are 99% idle, except when silly programmers try to execute infinite pooling loops or that sort of things. There is a myth (now banishing) that you need a real Unix of >100K$ to do the real work; think of the price of Sun's.
So apart from their trash PC hardware, I believe those kids with LAMP systems do really know a bit on stability and heavy load (think of /.)
Maybe they're shy to write ALSA in a Linux-centric site.
Interesting link, but the arguments are too similar to the classical die-hard C programmers that never did learn OO principles, kind of:
"you can create objects with structures and function pointers"
"several c-toolkits are already object oriented -for example, X-intrinsics, so we don't need this C++ crap".
Also, note that most (if not all) of the rant about the silly OO-constructs in PHP5 apply to Java... so the conclusion is that Perl is better than Java in OO support.
Maybe Slashdot.org can apply for a free license of DansGuardian to filter some inbound traffic?
>>> to the new Network Manager..
And hope this time let you set a really fixed ip address.
I hate the idea of a proliferation of AV software for Linux... people proposes that, because they assume that is a normal thing to live with a platform too vulnerable like MS... From install XP and Vista do "alert" that there is a "security problem" when there is no AV, so they assume from start that the OS or the apps are not (and can not be) correctly written at all.
So bad that people assumes that living with parasitic AV is normal/healthy; is like assuming that all people must carry guns every time.
But how many of those millions use their time to just untar the source code?... and to understand the source code?... and to fix the source code?
I think the advantage is that the (few?) FOSS hackers are not too compromised to a big business so they 1) can improve the security via best code quality without managers stopping the work because of profitability/marketing timelines, and 2) they do not need to hide or lie about the bad security issues.
>> trees tend to grow up unless they tend to grow down or sideways.
Of course you can expect a dramatic reduction in source code size as the 2.8 finally introduces C++, the full OO paradigm, several Go4 official design patterns, and a bit of eXtreme Programming in order to recruit more young programmers.
>>This destroys Microsoft's claim that their intimate knowledge of the OS that runs IE will increase performance.
After the criticisms about the "secret Windows APIs" Wikipedia the last thing M$ will do is to proclaim they have some exclusive "intimate knowledge". Of course, being the creator they should know the product better than most people.
At least this time was not a bad PHP script; the human race is improving.