He did a decent coverage of voting as well as gathered many comments on why M$ was destined to win.
Briefly, standardization process is made so that participation for every party is easy as possible and that interested parties can effectively communicate with each other using ISO infrastructures. Upshot is that organization which are interested in standard can do pretty much what they want.
Generally ISO is place where government bodies meet industry bodies and agree upon something. In the case of OOXML, M$ was alone - so it is essentially agreed with itself to accept the standard. All possible formalities were adhered to. All stuff of all committees had agreed on acceptance (because general practice is that interested parties (read M$) stuff the committee).
ISO process isn't corrupt. Nobody's expected that standardization has such a political side - since many government procurement procedures require agencies to use standards where available. M$ has overslept the ODF standardization and was literally stabbed in a back by ODF at many procurement deals: standard de jure trumps standard de facto there.
[...] the reason this is unsafe is only that the languages we use are unsafe.
Yeeees. Right. Absolutely.
This has nothing to do with sloppy programming and bunch of incompetent monkeys who managed to get to keyboard because it is cool.
The difference between good developer and bad developer is that good developer always listens to user feed back. To system developers that's application developers are users. To application developers that's end-users are users. To hardware developers that's system developers are users.
NT4 in that respect set all time record for shittiest programming ever. M$ with Win2k/WinXP/Vista was doing essentially one thing: making system simpler, system which wouldn't drive developers insane.
Most of previous Linux attempts to moving parts of graphics into kernel were hindered in some part by lack of documentation and most importantly oversized ego of some developers calling for revolution. But in fact there were no revolution and nothing extraordinary new was done: people were trying to randomly move stuff around kernel/user space, nothing more. GGI was classical example: you could do the same with X - but it wasn't ever tried nor done. Because its developers were dead set on changing everything - no compromises allowed. For sake of highly experimental project recrafting stable kernel interfaces? That will never happen. The fact now that most of the mod setting development is done under hood of X.Org is a sign that it is going to be done right - because it is going to be done using stable ground, not shaking foundation of highly experimental library.
Well, to be frank, I'm surprised that iPhone took off in Europe at all.
Before iPhone, over here in Germany, there were literally no affordable data rates. Now there are. But still those which are affordable are useless on iPhone due to the all the limits set low.
Also, 3G despite being rolled out all over Europe, still used by only fraction of people. So it is not really any major attraction.
If Celcos want to move more iPhones they have to lower data rates considerably, so they will be accessible to majority of European market - youth, students and alike.
The crucial difference is that Intel is one-stop CPU shop: they produce everything in house. AMD is much much smaller than Intel and often has to resort to outsourcing.http://slashdot.org/comments.pl?sid=526148&cid=23109172#
Cancel
What is important to Apple is that Intel delivers complete solution in several markets. AMD has lots of holes in its offerings which need to be filled by 3rd party components to make a product out of them. For Apple it is important to keep secret until product reaches market to rip additionally on wow-effect: dealing with many partners doesn't help.
Also, Intel can guarantee delivery - it owns 10+ fabs. AMD? Only 2 and only one of them is using modern process - only one fab to compete against Intel.
I'd say that the whole discussion is a praise to AMD, because the (relatively) small company is standing against giant Intel is. Thanks to open thinking of AMD (as opposed to corporate politicking of Intel) we have now affordable 64bit computing on our desks.
That reminds me of AMD before Opteron release. Their CPUs sucked because they were always catching up with Intel. Their finances sucked. Luckily for them Intel made strategical mistake (called Itanic thus giving AMD opportunity and enough time to release completely new architecture - AMD64.
I wonder if AMD will get lucky second time - in the repeated "nothing to lose" situation.
Did anybody actually tried to sell a new desktop system? Does anybody even make money on desktop software??
Servers. Big iron.
Because that's where you can sell pure technology. That's where most people are engineers - the people who are not biased by subjective perception: they buy what does work best for them.
That doesn't work for desktop software. Take a look at top two desktop OSs - Windows and MacOS - and try to recall how long it took for them to be where they are now. Inertness of desktop market is ridiculous: some people are still dreaming of Amiga OS...
Clearly, since you know what's aptitude is, Ubuntu isn't for you.
As much as I hate Ubuntu, you point is silly. Ubuntu is made so that even idiot can use it. If you are not idiot - then move on. But some people - especially some ex-Windows pro-users - are very happy to have stable OS and 6 month upgrade cycle which really improves OS.
When will the Ubuntu crowd come to their senses and finally understand that they are in fact running a DEBIAN system?
LOL. Whole point of Ubuntu that users (the "crowd") do not have to care about - least understand - what they are running.
Ubuntu is made for end-users as an OS which just runs and doesn't require any understanding of what and how it does.
That's pretty much why Ubuntu != Debian. Debian is technology - for engineers and advanced users who want total control over their system. Ubuntu is product - for those who used to buy stuff off the shelf and want it to just work. Feel the difference.
The question really isn't about POSIX compliance: many (e.g. me) users expect that/bin/sh is actually/bin/bash and nothing would change that.
From my understanding, the only significant use for ash and dash is bootstrap which is performance critical. They are not going to replace/bin/bash any time soon.
You just add extra group, put the the person in the group, change the group of the file to the new group and make it writable by the group.
It was proven (mathematically and practically) that UNIX model with ugo+rwx and directories allow one to emulate effect of ACLs. It's not straightforward - but it is possible.
On other side, Windows has problems because on one side engineers try to implement near perfect solution (e.g. NT). But then when you try to build OS on top of it you find that your simple program which under UNIX takes 5 lines under Windows takes about 200 lines of code.
UNIX security model isn't ideal: it has compromise included. But thanks to that it keeps many developers sane - and many users happy.
Windows tries perfect security - but nobody could program for it. Well, except for the SysInternals folks. But this is just exception confirming the rule.
The sound card parameters are floating far above human capability to hear.
At 120db signal-to-noise ratio, to hear the difference you need hi-fi components starting from $600, loudspeakers starting at $400 for piece and cables for $300. And even then you (as most others) probably wouldn't be able to tell difference.
But there are some people (especially musicians) who can tell the difference, appreciate the better quality and actually willing to pay for it. (And note that price is generally high not because they are expensive, but because sale volumes and demand are relatively low.)
For most uses of PC, signal to noise ratio of 80db is more than enough. The problem is of course few cards though boast even higher values, rarely do deliver: PC is crammed with many components which indirectly influence and degrade sound quality. For one, normal chinese power supplies are of terrible quality - and hardly suitable for use with such cards. Add here voltage variance induced by hard drive (re)spinning/seeking and video card draining amps to draw some accelerated 2/3D - and you got all what is required for poor audio quality.
.com.xx are pretty standard domains around the world.
.com.xx are generally used for commercial companies by national registrars as to not to flood second level domain system with bunch of quickly changing names. Not everybody has millions to dump into support of top level domains.
It's much harder to create from scratch than it is to review someone else's work or to add a small tweak.
This is not always true. Most of the time during review, people concentrate only on particular aspect of coding which leads to particular problems. But this is only half of code review. If you really need to find all possible problems in code under review, you also have to review all the places which use the code in question.
In my experience the "to create from scratch" is easier, but very unreliable and error-prone. Unless you have dug all whole of the code and understood all "how"s and "why"s, chances are big that newly created code would have same amount of problems. And understanding all "how"s and "why"s is what I call code review.
I try to avoid creating from scratch. Generally it is better practice to try to fix broken code. While you are fixing it you would understand it better and better. Then at some later point of time you would understand it so well that you would be ready for rewrite from scratch. But do not do it just right now. After some more time and more fixing you would understand so well, that you would easily come up with 10-or-so line fix which would fix all problems. Now, if you would compare original version and your new fixed version with oh-so-important 10-or-so-line-fix - you would notice that you have rewrote the whole program in the process - literally from scratch. That's my idealistic workflow for "creating from scratch" I try to adhere to. It allows to keep actually working (probably far from ideal) program and work on it in parallel without introducing major regressions. The process is much more manageable compared to tabula rasa rewrite.
Also, I often try to stick to backward-compatibility. Many people jump on rewrite from scratch, but instead of making improved version, they try to make a double jump by also introducing new functionality. Result is that new program cannot be tested in environment for old program, what is not good. If one does rewrite, then one has to make sure to do it in two steps: (first) make actual rewrite, provisioning new functionality and (second) only then introduce new functionality.
Did testing for couple of years. Really learned how to test what I code ^_^
But I did functional testing: dissecting source code into tiny pieces and then writing a program which would trigger nearly every line of code. But that's quite rare job I'd say. Generally most people get scared of working as testers - and there are many reasons to it: low pay, low profile, some amount of routine.
Good luck is also needed: testing code of some moron might add a considerable number of gray hairs. Testing good code written by good coder is rather easy and fast - fun doesn't last. Consequently most of the time one have to deal with morons who wrote the moronic code: because they are swarming you telling "code works perfectly! - you are using it wrong!!". That's one hell of boredom.
But there is nothing else what can teach one how to NOT write programs. For best results, it should be combined with some previous experience of writing actually working (and released to customers) programs: otherwise one can degrade into full-fledged boring tester, who only knows how and when to press buttons on screen.
P.S. Another positive side to testing: one learns architecture quite fast. Once you learn architecture of one system well - learning all other architectures would be much easier.
Even if you do not plan to use or program for Linux, the mail list has bunch of gurus often saying good thing. Try to code some driver or simple file system - anything what would look interesting to you. Try to post patches on mail list - comments often provided invaluable insight into how OS and HW function.
If you going be a system developer - Linux (or BSD) is good start point where you can participate easily. If you going to be application developer, then experience working with OS directly would prove very helpful later. In my experience biggest problem with application developer that they know sh*t about system they are using - what causes major pains later.
Another advise I can give is to train yourself for code review. This one helps to develop analytical thinking and would in future facilitate reading others code: invaluable skill for team work.
P.S. Another interesting place is BSD's libc. GNU libc - is horrific on inside. But BSD's one much simpler and easier to work with. libc contains hell a lot of knowledge about underlying system and how the system should be used. All the knowledge in easiest to consume form - source code. Also good place to gain experience.
P.P.S. I myself started with programming games. It is entertaining to write such program and very rewarding as result. Have started with x86 assembler and MS-DOS 3.1, I'm on my 7th Tetris by now - now in C++ and Qt4. Most importantly, simple projects like that serve as a perfect test ground for ideas: it is much cheaper to make a mistake in your hobby project than in million-lines-of-code commercial monster project.
Last time debunking was pretty quick: Apple also patches BSD sub-system with all the usual Unix apps.
Since for M$ only Windows patches were counted, then for fair comparison one has to exclude all the patches for all the command line utilities and Unix services (all of which are disabled by default) Apple does repackage and ship with OS just for our convenience.
IIRC, in the time of discussions, it was said that Xen can always use KVM.
KVM is essentially official kernel interface to virtualization hardware. But Xen has to work even without hardware support so they do lots of things on their own.
As soon as number of servers with hardware supported virtualization reaches critical mass, Xen would start using KVM where available since it is part of kernel, since it is official interface.
IOW, in long term Xen and KVM are complementing, not competing technologies.
[...] the vast majority of people signing the petition ARE Microsoft customers!
Microsoft doesn't sell directly. Amongst users of Windows there is no M$ customers.
M$'s customers are channel partners - those who sell Windows/Office/Server/etc for them.
M$ eagerly listens to its customers on how they can together make even more money. Right - not how to make product better - but how to secure more sale deals. That's the concept.
But then again, M$' channel partners sell the ware to IT departments. And we all know that IT is dead end as end-users are concerned. Nor IT does use even half of the product they procure.
So in the long chain to M$, your silly petition is just empty whining to them. After all, you already bought both Vista and XP - deal's sealed and done. So why you are whining then???
"Jean Paoli, Microsoft's senior director of XML technology":
"It has been fostered by a single company--IBM. If it was not for IBM, it would have been business as usual for this standard."
IBM's Sutor response:
"If 'business as usual' means trying to foist a rushed, technically inferior and product-specific piece of work like OOXML on the IT industry, we're proud to stand with the tens of countries and thousands of individuals who are willing to fight against such bad behavior."
RH never made a secret that Fedora is essentially a test bed for their commercial offering RHEL.
It would sound like rants, yet, the only people I know using Fedora are using it "unwillingly:" because their companies run RHEL, because their partners are using RHEL, because they need need to be compatible to RHEL, etc. I know nobody who uses Fedora because s/he likes it.
Fedora isn't bad at all. Yet, rough edges of corporate leadership are sticking out all over the place.
Slashdot Mirror
You should have read before Andy Updegrove's blog.
He did a decent coverage of voting as well as gathered many comments on why M$ was destined to win.
Briefly, standardization process is made so that participation for every party is easy as possible and that interested parties can effectively communicate with each other using ISO infrastructures. Upshot is that organization which are interested in standard can do pretty much what they want.
Generally ISO is place where government bodies meet industry bodies and agree upon something. In the case of OOXML, M$ was alone - so it is essentially agreed with itself to accept the standard. All possible formalities were adhered to. All stuff of all committees had agreed on acceptance (because general practice is that interested parties (read M$) stuff the committee).
ISO process isn't corrupt. Nobody's expected that standardization has such a political side - since many government procurement procedures require agencies to use standards where available. M$ has overslept the ODF standardization and was literally stabbed in a back by ODF at many procurement deals: standard de jure trumps standard de facto there.
Yeeees. Right. Absolutely.
This has nothing to do with sloppy programming and bunch of incompetent monkeys who managed to get to keyboard because it is cool.
The difference between good developer and bad developer is that good developer always listens to user feed back. To system developers that's application developers are users. To application developers that's end-users are users. To hardware developers that's system developers are users.
NT4 in that respect set all time record for shittiest programming ever. M$ with Win2k/WinXP/Vista was doing essentially one thing: making system simpler, system which wouldn't drive developers insane.
Most of previous Linux attempts to moving parts of graphics into kernel were hindered in some part by lack of documentation and most importantly oversized ego of some developers calling for revolution. But in fact there were no revolution and nothing extraordinary new was done: people were trying to randomly move stuff around kernel/user space, nothing more. GGI was classical example: you could do the same with X - but it wasn't ever tried nor done. Because its developers were dead set on changing everything - no compromises allowed. For sake of highly experimental project recrafting stable kernel interfaces? That will never happen. The fact now that most of the mod setting development is done under hood of X.Org is a sign that it is going to be done right - because it is going to be done using stable ground, not shaking foundation of highly experimental library.
Well, to be frank, I'm surprised that iPhone took off in Europe at all.
Before iPhone, over here in Germany, there were literally no affordable data rates. Now there are. But still those which are affordable are useless on iPhone due to the all the limits set low.
Also, 3G despite being rolled out all over Europe, still used by only fraction of people. So it is not really any major attraction.
If Celcos want to move more iPhones they have to lower data rates considerably, so they will be accessible to majority of European market - youth, students and alike.
The crucial difference is that Intel is one-stop CPU shop: they produce everything in house. AMD is much much smaller than Intel and often has to resort to outsourcing.http://slashdot.org/comments.pl?sid=526148&cid=23109172# Cancel
What is important to Apple is that Intel delivers complete solution in several markets. AMD has lots of holes in its offerings which need to be filled by 3rd party components to make a product out of them. For Apple it is important to keep secret until product reaches market to rip additionally on wow-effect: dealing with many partners doesn't help.
Also, Intel can guarantee delivery - it owns 10+ fabs. AMD? Only 2 and only one of them is using modern process - only one fab to compete against Intel.
I'd say that the whole discussion is a praise to AMD, because the (relatively) small company is standing against giant Intel is. Thanks to open thinking of AMD (as opposed to corporate politicking of Intel) we have now affordable 64bit computing on our desks.
That reminds me of AMD before Opteron release. Their CPUs sucked because they were always catching up with Intel. Their finances sucked. Luckily for them Intel made strategical mistake (called Itanic thus giving AMD opportunity and enough time to release completely new architecture - AMD64.
I wonder if AMD will get lucky second time - in the repeated "nothing to lose" situation.
Anybody surprised?
Did anybody actually tried to sell a new desktop system? Does anybody even make money on desktop software??
Because that's where you can sell pure technology. That's where most people are engineers - the people who are not biased by subjective perception: they buy what does work best for them.
That doesn't work for desktop software. Take a look at top two desktop OSs - Windows and MacOS - and try to recall how long it took for them to be where they are now. Inertness of desktop market is ridiculous: some people are still dreaming of Amiga OS...
Clearly, since you know what's aptitude is, Ubuntu isn't for you.
As much as I hate Ubuntu, you point is silly. Ubuntu is made so that even idiot can use it. If you are not idiot - then move on. But some people - especially some ex-Windows pro-users - are very happy to have stable OS and 6 month upgrade cycle which really improves OS.
LOL. Whole point of Ubuntu that users (the "crowd") do not have to care about - least understand - what they are running.
Ubuntu is made for end-users as an OS which just runs and doesn't require any understanding of what and how it does.
That's pretty much why Ubuntu != Debian.
Debian is technology - for engineers and advanced users who want total control over their system.
Ubuntu is product - for those who used to buy stuff off the shelf and want it to just work.
Feel the difference.
The question really isn't about POSIX compliance: many (e.g. me) users expect that /bin/sh is actually /bin/bash and nothing would change that.
From my understanding, the only significant use for ash and dash is bootstrap which is performance critical. They are not going to replace /bin/bash any time soon.
P.S. dash
You just add extra group, put the the person in the group, change the group of the file to the new group and make it writable by the group.
It was proven (mathematically and practically) that UNIX model with ugo+rwx and directories allow one to emulate effect of ACLs. It's not straightforward - but it is possible.
On other side, Windows has problems because on one side engineers try to implement near perfect solution (e.g. NT). But then when you try to build OS on top of it you find that your simple program which under UNIX takes 5 lines under Windows takes about 200 lines of code.
UNIX security model isn't ideal: it has compromise included. But thanks to that it keeps many developers sane - and many users happy.
Windows tries perfect security - but nobody could program for it. Well, except for the SysInternals folks. But this is just exception confirming the rule.
Absolutely not!
This are kids who are too quick to dismiss educational part of gaming!!
The sound card parameters are floating far above human capability to hear.
At 120db signal-to-noise ratio, to hear the difference you need hi-fi components starting from $600, loudspeakers starting at $400 for piece and cables for $300. And even then you (as most others) probably wouldn't be able to tell difference.
But there are some people (especially musicians) who can tell the difference, appreciate the better quality and actually willing to pay for it. (And note that price is generally high not because they are expensive, but because sale volumes and demand are relatively low.)
For most uses of PC, signal to noise ratio of 80db is more than enough. The problem is of course few cards though boast even higher values, rarely do deliver: PC is crammed with many components which indirectly influence and degrade sound quality. For one, normal chinese power supplies are of terrible quality - and hardly suitable for use with such cards. Add here voltage variance induced by hard drive (re)spinning/seeking and video card draining amps to draw some accelerated 2/3D - and you got all what is required for poor audio quality.
And here I thought that sound card market gradually died, being consumed and obliterated by on-board, embedded in chipset audio adapters.
For 90% of uses the adapters are "good enough." For everything else I have an iPod.
What are you smoking??
Since when DVI started supporting audio?
This is not always true. Most of the time during review, people concentrate only on particular aspect of coding which leads to particular problems. But this is only half of code review. If you really need to find all possible problems in code under review, you also have to review all the places which use the code in question.
In my experience the "to create from scratch" is easier, but very unreliable and error-prone. Unless you have dug all whole of the code and understood all "how"s and "why"s, chances are big that newly created code would have same amount of problems. And understanding all "how"s and "why"s is what I call code review.
I try to avoid creating from scratch. Generally it is better practice to try to fix broken code. While you are fixing it you would understand it better and better. Then at some later point of time you would understand it so well that you would be ready for rewrite from scratch. But do not do it just right now. After some more time and more fixing you would understand so well, that you would easily come up with 10-or-so line fix which would fix all problems. Now, if you would compare original version and your new fixed version with oh-so-important 10-or-so-line-fix - you would notice that you have rewrote the whole program in the process - literally from scratch. That's my idealistic workflow for "creating from scratch" I try to adhere to. It allows to keep actually working (probably far from ideal) program and work on it in parallel without introducing major regressions. The process is much more manageable compared to tabula rasa rewrite.
Also, I often try to stick to backward-compatibility. Many people jump on rewrite from scratch, but instead of making improved version, they try to make a double jump by also introducing new functionality. Result is that new program cannot be tested in environment for old program, what is not good. If one does rewrite, then one has to make sure to do it in two steps: (first) make actual rewrite, provisioning new functionality and (second) only then introduce new functionality.
+100.
Did testing for couple of years. Really learned how to test what I code ^_^
But I did functional testing: dissecting source code into tiny pieces and then writing a program which would trigger nearly every line of code. But that's quite rare job I'd say. Generally most people get scared of working as testers - and there are many reasons to it: low pay, low profile, some amount of routine.
Good luck is also needed: testing code of some moron might add a considerable number of gray hairs. Testing good code written by good coder is rather easy and fast - fun doesn't last. Consequently most of the time one have to deal with morons who wrote the moronic code: because they are swarming you telling "code works perfectly! - you are using it wrong!!". That's one hell of boredom.
But there is nothing else what can teach one how to NOT write programs. For best results, it should be combined with some previous experience of writing actually working (and released to customers) programs: otherwise one can degrade into full-fledged boring tester, who only knows how and when to press buttons on screen.
P.S. Another positive side to testing: one learns architecture quite fast. Once you learn architecture of one system well - learning all other architectures would be much easier.
There is a popular belief that friendship is possible between opposite sexes.
Load of bullocks. There is no such thing as "friendship" between a man and a woman.
Linux Kernel Mail List.
Even if you do not plan to use or program for Linux, the mail list has bunch of gurus often saying good thing. Try to code some driver or simple file system - anything what would look interesting to you. Try to post patches on mail list - comments often provided invaluable insight into how OS and HW function.
If you going be a system developer - Linux (or BSD) is good start point where you can participate easily. If you going to be application developer, then experience working with OS directly would prove very helpful later. In my experience biggest problem with application developer that they know sh*t about system they are using - what causes major pains later.
Another advise I can give is to train yourself for code review. This one helps to develop analytical thinking and would in future facilitate reading others code: invaluable skill for team work.
P.S. Another interesting place is BSD's libc. GNU libc - is horrific on inside. But BSD's one much simpler and easier to work with. libc contains hell a lot of knowledge about underlying system and how the system should be used. All the knowledge in easiest to consume form - source code. Also good place to gain experience.
P.P.S. I myself started with programming games. It is entertaining to write such program and very rewarding as result. Have started with x86 assembler and MS-DOS 3.1, I'm on my 7th Tetris by now - now in C++ and Qt4. Most importantly, simple projects like that serve as a perfect test ground for ideas: it is much cheaper to make a mistake in your hobby project than in million-lines-of-code commercial monster project.
Actually it reads like deja vu.
Last time debunking was pretty quick: Apple also patches BSD sub-system with all the usual Unix apps.
Since for M$ only Windows patches were counted, then for fair comparison one has to exclude all the patches for all the command line utilities and Unix services (all of which are disabled by default) Apple does repackage and ship with OS just for our convenience.
IIRC, in the time of discussions, it was said that Xen can always use KVM.
KVM is essentially official kernel interface to virtualization hardware. But Xen has to work even without hardware support so they do lots of things on their own.
As soon as number of servers with hardware supported virtualization reaches critical mass, Xen would start using KVM where available since it is part of kernel, since it is official interface.
IOW, in long term Xen and KVM are complementing, not competing technologies.
That's what I hate most in security guys - they are out of reality.
Because any real guy from real world with functioning brains would have said:
It's just little hint that the guy - Peter Tippett - is not with us (mere mortal users) but with the "security pros."
Microsoft doesn't sell directly. Amongst users of Windows there is no M$ customers.
M$'s customers are channel partners - those who sell Windows/Office/Server/etc for them.
M$ eagerly listens to its customers on how they can together make even more money. Right - not how to make product better - but how to secure more sale deals. That's the concept.
But then again, M$' channel partners sell the ware to IT departments. And we all know that IT is dead end as end-users are concerned. Nor IT does use even half of the product they procure.
So in the long chain to M$, your silly petition is just empty whining to them. After all, you already bought both Vista and XP - deal's sealed and done. So why you are whining then???
To me key quotes were:
"Jean Paoli, Microsoft's senior director of XML technology" :
IBM's Sutor response :
Nuff' said: IBM won the war of words.
RH never made a secret that Fedora is essentially a test bed for their commercial offering RHEL.
It would sound like rants, yet, the only people I know using Fedora are using it "unwillingly:" because their companies run RHEL, because their partners are using RHEL, because they need need to be compatible to RHEL, etc. I know nobody who uses Fedora because s/he likes it.
Fedora isn't bad at all. Yet, rough edges of corporate leadership are sticking out all over the place.