If, for argument's sake, MSVC has a feature that's missing from GCC and this feature results in 5% faster code for some app -- well, more power to MSVC.
Google was a Black Swan -- that's why I wouldn't even count Altavista and others that were present before Google. With the metadata/keyword based ranking they used it was trivial to game the system -- so Google overtook them just by being there. The other thing Google were the first to figure out: monetizing search. Nobody was able to make money off it until they showed the way.
Having said that, you don't necessarily need a black swan to beat google. It'll help, but it might not be required. It'll prpbably just take more dogged persistence. Time will tell.
An example of said persistence: Having deep enough pockets to go the distance. Being able to get partnerships with as many vendors as possible to set your search as the default search on their device/service/whatever. That's half the fight right there. Because without clicks, you're missing the feedback you need to tune your results (never mind the revenue it generates). And without that, you're never going to get better results. So you have to parner with OEMS, carriers (or smartphone makers), browser makers, DNS providers (for your typical DNS erros when an address can't be found -- it's usually a search on the address you're looking up). etc. All this takes persistence and deep pockets. Hence, nobody other than MS is in a position to challenge Google.
heh.. I think the lemur doesn't have much of a choice -- the Gorilla's been trying to visit the Lemur's cage of late (y'know, Chrome, Android, Google Docs, etc.)
You're probably correct, but by the same token, Google has taken over the search market by competing with incompetence.
I wouldn't call their competitors incompetant - but I would call them absent. I mean, Yahoo still can't decide if they're actually a competitor in search or not. MS themselves only decided to focus on search around 4 years ago. So Google's been able to pretty much do their own thing for a while now.
I'm not personally convinced that the Google engine is really that good, in fact by design it's all but worthless for certain types of query. Originally it was designed to be fast and to not need to be able to comprehend the content of the page. Over the years they've had to change that because of the gamesmanship that inevitably occurs when you're at the top. And for the queries that I like to make, it doesn't do any better job of finding things than the older MS search did.
I wouldn't go that far (as to say that Google's search is not good). Google are certainly not the first company to tackle search (I'm sure you remember AltaVista, for example). To their credit, even in absense of credible competitors they haven't been standing still. They've added a lot of 'smartness' to their results over the years. But they've definitely accelerated that pace over the last 2 or 3 years. But maybe lack of stagnation is just a question of perception - maybe after Bing and Google slug it out for a few years we'll look back at search as it exists today and think, "well, that was pretty fucking lame".. Only time will tell. But I do agree with you -- for that to happen, there has to be a credible competitor. And at the moment that competitor is Bing.
"Taking notice" might be an apt phrase to describe Google's reaction -- but even "concern" would be seriously overstating it -- never mind something like "panic" or "running scared".
Having said that, it's nice to see some competition in search, just as it's nice to see Macs and Linux keeping Windows honest.
Code reviews also have an important place in secure development processes. It's important to train all your devs on secure development practices and then have them look for insecure coding while reviewing code. It's not a substitute to having a security expert (in-house or consultant) audit your code - but it's still a valuable step to catch low-hanging stuff like silliness with string buffers, absent-minded sizeof calculations (that could lead to buffer overrun vulnerabilities), etc.
Another common defect that tends to be caught in code reviews -- memory leaks. It's nothing that a half-decent stress test won't catch, but I've seen a lot of companies do very half-assed testing with no proper stress testing / leak detection etc. It's relatively common to see a developer forget to close a handle, or absentmindedly use the wrong function to close a handle (happens when using non object-oriented APIs with multiple handle types and consequently multiple handle closing functions) -- this is exacerbated by the fact that people rarely check the return status of a close-handle call. Sometimes even memory allocation/deallocation issues get caught in code reviews.
And of couse, that's no substitute for proper stress testing / memory profiling / leak detection.
I've found that the best way to maximize what you're getting out of code reviews is to give some thought to what benefits you could get out of it (for example, if you're developing in C# you can toss out the string buffer stuff above, but you can add stuff like dereferencing..). Obviously you should solicit input from all your devs in this step. Next, you should compile that information into an informal guideline (or rather "'things to keep in mind checklist") that people can pin to the wall. Take 10 seconds to scan the list before doing a code-review -- it helps align your thoughts in terms of what you're looking for in the code review.
A person with any level of objectivity (or logic) would know that the onus lies on the accuser to provide evidence of shenanigans. Innocent until proven guilty - remember?
Linux distributions can do this, so why can't Microsoft?
Linux distributions can bundle a browser, so why can't Micsosoft?
OS-X can bundle a browser, so why can't Microsoft?
Further - what's to prevent the EU from going after MS for providing free CDs of IE (and only IE) with Win7? They haven't showed much logic in this particular witch-hunt/ATM-withdrawal.
No, you're just ingorant. I'll demonstrate in the next line.
1. Retail boxes of Windows from Microsoft will still contain IE. What this is doing is allowing OEM's to put different arrangements of browsers on a retail machine.
From TFA: "This will apply to both OEM and Retail versions of Windows 7 products." - next time you want to start calling people idiots/shills and display strong but ingorant views, I suggest reading the article first.
2. Yes, one allowed arrangement is "no IE", although that is very unlikely. A far more likely arrangement is "IE and Firefox", something that Microsoft did not allow before or the OEM would lose their volume discount. Note that there are TWO (count em) browsers, although in your fantasy astroturf world the ONLY thing that counts is "IE is removed", despite the fact that you and I both know that nobody is going to do that.
You're still lacking any citation for your claim about the OEM losing volume licensing if they bundle a different browser. Take your time searching for one and then reply back.
For that matter, OEMs themselves were free to take the hassle/cost of installing a different browser if they so desired.
You blew it there. That is a LIE.
I repeat - you need a citation to back up your rhetoric.
How many idiots are here on/. you ask? Well, I'm replying to one right now.
I don't know if it is stupidity or Microsoft shills.
...
However if you read the fa, or even if you think a little bit:
NOBODY IS GOING TO SELL A COMPUTER WITHOUT A BROWSER!
What about retail box sales of Windows genius? Novice users do clean installs / upgrades too.
The machine the end user gets will have a browser. Likely more than one. Probably the blue E and the firefox will be on the desktop. The user can click on either one.
I repeat - what about retail sales, genius? Or let me guess -- you think it's ok because only about 10 to 15 percent of sales will be retail sales.
This is what Microsoft did not allow before and what they have been forced to allow.
Bullshit. The EU is still in the process of querying OEMS -- they themselves do not have evidence of MS disallowing this or using any strong-arm tactics -- so what evidence do you have?
They are still up to the same shit, saying "IE is missing" without saying exactly what they were forced to do.
And now you're just rambling. What is your point? How does it make a difference to you if the trident engine is present on the machine (for.cmh files etc. to work) if you cannot launch IE once you have uninstalled it?
And finally, since you appear to have such a well-thought out stance on this (yes, I'm being sarcastic), answer this:
1) What qualifies a browser to be pre-installed on a machine by an OEM - customer demand? features? security? compatibility? reliability? standards compliance?
2) What makes you think you, or the EU, or the OEM is in the best position to make that decision for consumers?
4) Who will bear the cost of automating the install, doing compatibility testing, etc. (possibly on multiple browsers)?
I suspect, the OEMs were perfectly happy with not having to get involved in this thus far. It's one less hassle, and one less customization cost for them on the machines they sell. And users were always free to go download a different browser if they so desired. For that matter, OEMs themselves were free to take the hassle/cost of installing a different browser if they so desired.
Guess what - nobody cared. For all the rhetoric around the issue, it's just a freaking browser in the end, the EU doesn't give a damn about user's convenience, and it's just making another ATM withdrawal.
So you're saying something along the lines of:
1) Linux sucks (or is not a viable alternative)
2) Mac hardware is too expensive
So MS must continue to sell XP?
So if:
1) Linux remains a non-viable alternative
2) Mac hardware continues to be too expensive
3) No other viable competitor turns up
MS must never obsolete/discontinue support for/stop selling any OS they release in Russia?
How the does this work? If Linux (or FOSS in general) can't nail what the market wants, and Apple can't nail what the market wants, we should go and penalize MS for it??
It's not that they're missing an opportunity -- it's just that this opportunity doesn't necessarily mean anything for them.
They're just in the business of selling computers. They'll put whatever OS they can, subject to the OS cost / customer support costs / customer demand equation falls in their favor. See netbooks as an example of that. PC vendors couldn't care less about FOSS/closed source/Windows/Linux etc. -- they just want to ship PCs and whatever works wherever will be what they go with.
I disagree -- I think there's a bunch of reasons WM has issues, and this is pretty low in the pecking order.
But specifically - when it comes to app design, it isn't so much a question of porting directly from the desktop -- it's a lack of mobile UI paradigms in the framework that stunts WM.
The easiest example is touch scrolling on the iphone vs. scroll bars on windows mobile. Scroll bars are a desktop paradigm. Touch scrolling is a mobile device paradigm. No mobile app should ever require the user to home in on a 2mm thick scroll bar using a 1-inch thick thumb. Not to mention the already limited screen real-estate that's getting wasted in displaying the scroll bar.
That's something MS needs to fix in their app development framework. Everyone writing / proting an app for WM shouldn't have to rewrite the code for that. Even if developers take the effort to do that, you get varying implementations resulting in an incoherent user experience (which is exactly what you have on WM).
Also consider radio buttons - why click on a tiny little circle instead of just using the entire text of the selection as the button itself, and use 3D effects to show which option is selected? An common zoom mechanism would be useful too. The start menu is a terrible idea on a screen as small as a QVGA -- a lot of people run out of space in the programs launcher on their desktops!!
The one thing I'll give WM a lot of credit for (which most people hate about it) -- the home/today screen. It actually gives me useful information unlike an iphone. I don't get any information from seeing a screen full of icons. They're useful, and it's nice to have everything so accessable, but keeping the icons one click away wouldn't have been too much overhead. The thing I miss on an iphone is being able to see my emails (broken down by account type - gmail/outlook/hotmail/etc.), my upcoming meetings, and being able to just type a contact name without needing to go to any screen. Those are the main functions of a 'communications' device that need to be available to me at all times, and WM absolutely nailed that aspect.
The cost on the environment is difficult to put a price tag on.
That's kinda the point actually -- that this cost is so difficult to take into consideration.
Consider the options a company could have:
1) Use the cheapest options available -- green or non-green be damned.
2) Use the green option without being asked/forced to -- i.e. risk higher operational costs than your competitors in your own country (and there will be competitors that won't go green if it gives them an advantage)
3) Be forced (by say government regulations) to use the green option -- i.e. this entire industry in this country now has higher operational costs -- and is now vulnerable to foreign competition (and there will be foreign competition that won't go green if it gives them an advantage).
So my point is -- we need to make the environmentally friendly option the cheaper option! I know you just said that the environmentally friendly option will always be more expensive -- but that's exactly the mindset (of the environmentalists) that I want to attack -- that we should not accept that as the bar. If we do accept that as a truism, the result is that there will always be someone more hungry or more desperate or just more greedy who will use the non-green method to get ahead. There will always be consumers poor enough or sufficiently non-rich who will not be able to spend more on the green option. There will always be countries whose governments don't really care about enforcing green rules etc. (because it helps their economy not to do so). The only alternative is for the green option to be the economic option. And once that option exists, the environmental lobbyists should absolutely evangelize it to the hilt!
If you think about it, data centers in the US must be Green.
Especially if they are built by Google, MSFT, or Apple.
We should demand that 100 percent of the anticipated max power draw of all "needed" data centers come from new construction of alternate energy sources - e.g. tidal, solar, wind, geothermal,hydro - that is literally BUILT in America to provide new power.
The days of power centers being built as if it doesn't matter that they contribute to global warming and help fund terrorists are over.
Umm.. you (we) don't need to *demand* anything here. Operational cost is the single most important metric of operating a datacenter. More so than even storage cost (which is a contributing factor to operating costs). Any company operating datacenter(s) is already looking into every manner imaginable to cut the cost of powering it. If a non-green cost is significantly cheaper, the company will simply not go green. If you tax stuff to make greenness more attractive (say a carbon tax) they will automatically shift to green sources. If the green source is cheaper to begin with, they will go green all the way.
For the environmentalists -- don't spend cycles on forcing people to adopt stuff that doesn't work for them. People in general want to do the right thing. You just have to spend your cycles on making the green thing the right thing. Make the environmentally friendly option equal to or cheaper than the non-environmentally option, and people will automatically do the right thing.
So you're arguing that MS's lawyers are completely incompetent and didn't know that being incompatible was a violation of antirust law and that antitrust law doesn't mention anything about standards compliance? I think that's a naive.
Whaaa? You just wrote an entire line of BS with a straight face. Good job.
They already own BSD licensed code that works on MS Office. Next argument please!
You can't take GPLd code (or a derivative thereof) and release it under a BSD license. Next.
But it's clear an precise enough that it worked for everyone else and there are multiple working open source implementations, one of which they can literally copy and paste from and which they helped fund the creation of and probably have full rights to it even if it wasn't BSD licensed. Sorry, that argument doesn't fly either.
???
1. Get this copy-paste notion out of your head. BSD and GPL are not compatible licenses.
2. "Many implementations that do the same thing" is not the same as "all these implementations follow the ODF standard".
Then there are cases where the popular ODF implementations aren't compliant with the spec.
Example please.
Will this suffice? How about this?
Quote: "So these two ODF implementations (OpenOffice and Symphony) do not have predictable formula interoperability, regardless of where you start. And these are not obscure implementations - they are the latest released versions of the implementations from IBM and Sun, the two companies that together chair the ODF Technical Committee"
They already did. MS doesn't want a standard for interoperability. They are simply looking for any way they can be compliant but still be incompatible.
I have a simpler theory -- you don't actually know anything about the standard and are just spouting off anything that comes to your mind.
Not really, that's what reference implementations are for. If you have any doubt about how to handle this, see the reference implementations and do it that way.
Gee, that way OOXML is a brilliantly well-defined standard.
The only argument you made that has any legs is the first one regarding compliance with the spec, but only if you assume ignorance of the law (I assume you perhaps aren't that familiar with antitrust law). I assure you, while it may at times appear that all of MS's lawyers have never heard of antitrust law, that is not the case in reality.
Very bold claim there. Wanna back it up with some legalese? How about you point us to this section of antitrust law that deals with compatibility taking precedence over standards compliance?
The kicker -- this consortium (ODF Alliance) is really just coming off as some sort of FUD-monger in this (don't kid yourself -- FOSS related entities use FUD too -- ain't nobody got a monopoly on FUD). The ODF alliance can invest cycles in fixing their standard, or in fixing their own implementations - heck they can even contribute to improving the compliance of MS's ODF converters (they're open source after all). OR, they can spend cycles on FUD. For example, their point about MS's commitment to support future versions of ODF. Also, their whining about lack of 'native' support for ODF in Office 2003 (this product was released 2 years before the ODF standard was ratified, for fucks sake). Then, they linked to other FUD (claiming MS is trying to fragment ODF).
At one point, they themselves concede that they don't have their shit together when it comes to spreadsheet formulas: "Though spreadsheet formula for ODF 1.0/1.1 (the version which Microsoft claims it supports in Office 2007) are implementation-d
Nothing special at all. It's slashdot, kdawson fud, slow news day, or some combination thereof.
I mean, reading the stuff on this thread, you'd think nobody ever downloaded trialware from the 'net that became full-featured on coughing up some dough.
Nothing but another reason to bash MS and think that somehow that's a meaningful contribution to the world.
Yeah, you're right -- static analyzers already should (and do) catch these things. But it's still worth it to decouple the thinking (and hence the handling) of the size of the source and destination. i.e. you have that as your prime motive for banning this API, and the static analyzer as the fallback to guard against the bad habit of just passing in the exact same varabile as source size and destination size.
Remember, ultimately all of this can be defeated by a programmer who's determined to be insecure/stupid. He/she could just put in some #pragma at that statement that tells the static analyzer "this is cool -- don't throw an alert when you see it" and then pass in the same variable. i.e. this coder has gone and defeated the purpose of both the banned API list and the static analyzer. So there's no magic bullet for sure. But that doesn't mean you shouldn't make whatever improvements you can -- and this is definitely a Good Thing.
Slashdot Mirror
Why is it important to use equivalent options?
If, for argument's sake, MSVC has a feature that's missing from GCC and this feature results in 5% faster code for some app -- well, more power to MSVC.
"0, Troll" -- that's sad. Disagreeing with parent is fine (likely even) but by silenting his dissent the mods essentially prove his point.
Google was a Black Swan -- that's why I wouldn't even count Altavista and others that were present before Google. With the metadata/keyword based ranking they used it was trivial to game the system -- so Google overtook them just by being there. The other thing Google were the first to figure out: monetizing search. Nobody was able to make money off it until they showed the way.
Having said that, you don't necessarily need a black swan to beat google. It'll help, but it might not be required. It'll prpbably just take more dogged persistence. Time will tell.
An example of said persistence: Having deep enough pockets to go the distance. Being able to get partnerships with as many vendors as possible to set your search as the default search on their device/service/whatever. That's half the fight right there. Because without clicks, you're missing the feedback you need to tune your results (never mind the revenue it generates). And without that, you're never going to get better results. So you have to parner with OEMS, carriers (or smartphone makers), browser makers, DNS providers (for your typical DNS erros when an address can't be found -- it's usually a search on the address you're looking up). etc. All this takes persistence and deep pockets. Hence, nobody other than MS is in a position to challenge Google.
It's a bit of a self-fulfilling prophecy though.
Maybe if the FOSS community were to stop ostracizing Novell for working with MS, and actually tried to help, then that wouldn't be the case.
Nope, I pretty much typed what I intended to. Unless I misunderstood your point.
heh.. I think the lemur doesn't have much of a choice -- the Gorilla's been trying to visit the Lemur's cage of late (y'know, Chrome, Android, Google Docs, etc.)
You're probably correct, but by the same token, Google has taken over the search market by competing with incompetence.
I wouldn't call their competitors incompetant - but I would call them absent. I mean, Yahoo still can't decide if they're actually a competitor in search or not. MS themselves only decided to focus on search around 4 years ago. So Google's been able to pretty much do their own thing for a while now.
I'm not personally convinced that the Google engine is really that good, in fact by design it's all but worthless for certain types of query. Originally it was designed to be fast and to not need to be able to comprehend the content of the page. Over the years they've had to change that because of the gamesmanship that inevitably occurs when you're at the top. And for the queries that I like to make, it doesn't do any better job of finding things than the older MS search did.
I wouldn't go that far (as to say that Google's search is not good). Google are certainly not the first company to tackle search (I'm sure you remember AltaVista, for example). To their credit, even in absense of credible competitors they haven't been standing still. They've added a lot of 'smartness' to their results over the years. But they've definitely accelerated that pace over the last 2 or 3 years. But maybe lack of stagnation is just a question of perception - maybe after Bing and Google slug it out for a few years we'll look back at search as it exists today and think, "well, that was pretty fucking lame".. Only time will tell. But I do agree with you -- for that to happen, there has to be a credible competitor. And at the moment that competitor is Bing.
I agree.
"Taking notice" might be an apt phrase to describe Google's reaction -- but even "concern" would be seriously overstating it -- never mind something like "panic" or "running scared".
Having said that, it's nice to see some competition in search, just as it's nice to see Macs and Linux keeping Windows honest.
Absolutely dead right.
Code reviews also have an important place in secure development processes. It's important to train all your devs on secure development practices and then have them look for insecure coding while reviewing code. It's not a substitute to having a security expert (in-house or consultant) audit your code - but it's still a valuable step to catch low-hanging stuff like silliness with string buffers, absent-minded sizeof calculations (that could lead to buffer overrun vulnerabilities), etc.
Another common defect that tends to be caught in code reviews -- memory leaks. It's nothing that a half-decent stress test won't catch, but I've seen a lot of companies do very half-assed testing with no proper stress testing / leak detection etc. It's relatively common to see a developer forget to close a handle, or absentmindedly use the wrong function to close a handle (happens when using non object-oriented APIs with multiple handle types and consequently multiple handle closing functions) -- this is exacerbated by the fact that people rarely check the return status of a close-handle call. Sometimes even memory allocation/deallocation issues get caught in code reviews.
And of couse, that's no substitute for proper stress testing / memory profiling / leak detection.
I've found that the best way to maximize what you're getting out of code reviews is to give some thought to what benefits you could get out of it (for example, if you're developing in C# you can toss out the string buffer stuff above, but you can add stuff like dereferencing..). Obviously you should solicit input from all your devs in this step. Next, you should compile that information into an informal guideline (or rather "'things to keep in mind checklist") that people can pin to the wall. Take 10 seconds to scan the list before doing a code-review -- it helps align your thoughts in terms of what you're looking for in the code review.
A person with any level of objectivity (or logic) would know that the onus lies on the accuser to provide evidence of shenanigans. Innocent until proven guilty - remember?
Linux distributions can do this, so why can't Microsoft?
Linux distributions can bundle a browser, so why can't Micsosoft?
OS-X can bundle a browser, so why can't Microsoft?
Further - what's to prevent the EU from going after MS for providing free CDs of IE (and only IE) with Win7? They haven't showed much logic in this particular witch-hunt/ATM-withdrawal.
Oh my god, you are really getting desperate, huh?
No, you're just ingorant. I'll demonstrate in the next line.
1. Retail boxes of Windows from Microsoft will still contain IE. What this is doing is allowing OEM's to put different arrangements of browsers on a retail machine.
From TFA: "This will apply to both OEM and Retail versions of Windows 7 products." - next time you want to start calling people idiots/shills and display strong but ingorant views, I suggest reading the article first.
2. Yes, one allowed arrangement is "no IE", although that is very unlikely. A far more likely arrangement is "IE and Firefox", something that Microsoft did not allow before or the OEM would lose their volume discount. Note that there are TWO (count em) browsers, although in your fantasy astroturf world the ONLY thing that counts is "IE is removed", despite the fact that you and I both know that nobody is going to do that.
You're still lacking any citation for your claim about the OEM losing volume licensing if they bundle a different browser. Take your time searching for one and then reply back.
For that matter, OEMs themselves were free to take the hassle/cost of installing a different browser if they so desired.
You blew it there. That is a LIE.
I repeat - you need a citation to back up your rhetoric.
How many idiots are here on /. you ask? Well, I'm replying to one right now.
I don't know if it is stupidity or Microsoft shills.
...
However if you read the fa, or even if you think a little bit:
NOBODY IS GOING TO SELL A COMPUTER WITHOUT A BROWSER!
What about retail box sales of Windows genius? Novice users do clean installs / upgrades too.
The machine the end user gets will have a browser. Likely more than one. Probably the blue E and the firefox will be on the desktop. The user can click on either one.
I repeat - what about retail sales, genius? Or let me guess -- you think it's ok because only about 10 to 15 percent of sales will be retail sales.
This is what Microsoft did not allow before and what they have been forced to allow.
Bullshit. The EU is still in the process of querying OEMS -- they themselves do not have evidence of MS disallowing this or using any strong-arm tactics -- so what evidence do you have?
They are still up to the same shit, saying "IE is missing" without saying exactly what they were forced to do.
And now you're just rambling. What is your point? How does it make a difference to you if the trident engine is present on the machine (for .cmh files etc. to work) if you cannot launch IE once you have uninstalled it?
And finally, since you appear to have such a well-thought out stance on this (yes, I'm being sarcastic), answer this:
1) What qualifies a browser to be pre-installed on a machine by an OEM - customer demand? features? security? compatibility? reliability? standards compliance?
2) What makes you think you, or the EU, or the OEM is in the best position to make that decision for consumers?
4) Who will bear the cost of automating the install, doing compatibility testing, etc. (possibly on multiple browsers)?
I suspect, the OEMs were perfectly happy with not having to get involved in this thus far. It's one less hassle, and one less customization cost for them on the machines they sell. And users were always free to go download a different browser if they so desired. For that matter, OEMs themselves were free to take the hassle/cost of installing a different browser if they so desired.
Guess what - nobody cared. For all the rhetoric around the issue, it's just a freaking browser in the end, the EU doesn't give a damn about user's convenience, and it's just making another ATM withdrawal.
You expect that level of competency, but you don't expect people to just download FF if they already have IE? Double-standard, no?
And we're supposed to conjure up the address how?
??
So you're saying something along the lines of:
1) Linux sucks (or is not a viable alternative)
2) Mac hardware is too expensive
So MS must continue to sell XP?
So if:
1) Linux remains a non-viable alternative
2) Mac hardware continues to be too expensive
3) No other viable competitor turns up
MS must never obsolete/discontinue support for/stop selling any OS they release in Russia?
How the does this work? If Linux (or FOSS in general) can't nail what the market wants, and Apple can't nail what the market wants, we should go and penalize MS for it??
It's not that they're missing an opportunity -- it's just that this opportunity doesn't necessarily mean anything for them.
They're just in the business of selling computers. They'll put whatever OS they can, subject to the OS cost / customer support costs / customer demand equation falls in their favor. See netbooks as an example of that. PC vendors couldn't care less about FOSS/closed source/Windows/Linux etc. -- they just want to ship PCs and whatever works wherever will be what they go with.
I disagree -- I think there's a bunch of reasons WM has issues, and this is pretty low in the pecking order.
But specifically - when it comes to app design, it isn't so much a question of porting directly from the desktop -- it's a lack of mobile UI paradigms in the framework that stunts WM.
The easiest example is touch scrolling on the iphone vs. scroll bars on windows mobile. Scroll bars are a desktop paradigm. Touch scrolling is a mobile device paradigm. No mobile app should ever require the user to home in on a 2mm thick scroll bar using a 1-inch thick thumb. Not to mention the already limited screen real-estate that's getting wasted in displaying the scroll bar.
That's something MS needs to fix in their app development framework. Everyone writing / proting an app for WM shouldn't have to rewrite the code for that. Even if developers take the effort to do that, you get varying implementations resulting in an incoherent user experience (which is exactly what you have on WM).
Also consider radio buttons - why click on a tiny little circle instead of just using the entire text of the selection as the button itself, and use 3D effects to show which option is selected? An common zoom mechanism would be useful too. The start menu is a terrible idea on a screen as small as a QVGA -- a lot of people run out of space in the programs launcher on their desktops!!
The one thing I'll give WM a lot of credit for (which most people hate about it) -- the home/today screen. It actually gives me useful information unlike an iphone. I don't get any information from seeing a screen full of icons. They're useful, and it's nice to have everything so accessable, but keeping the icons one click away wouldn't have been too much overhead. The thing I miss on an iphone is being able to see my emails (broken down by account type - gmail/outlook/hotmail/etc.), my upcoming meetings, and being able to just type a contact name without needing to go to any screen. Those are the main functions of a 'communications' device that need to be available to me at all times, and WM absolutely nailed that aspect.
It is based on touch -- just implemented using cameras and pattern recognition instead of capacitive or resistive films.
The cost on the environment is difficult to put a price tag on.
That's kinda the point actually -- that this cost is so difficult to take into consideration.
Consider the options a company could have:
1) Use the cheapest options available -- green or non-green be damned.
2) Use the green option without being asked/forced to -- i.e. risk higher operational costs than your competitors in your own country (and there will be competitors that won't go green if it gives them an advantage)
3) Be forced (by say government regulations) to use the green option -- i.e. this entire industry in this country now has higher operational costs -- and is now vulnerable to foreign competition (and there will be foreign competition that won't go green if it gives them an advantage).
So my point is -- we need to make the environmentally friendly option the cheaper option! I know you just said that the environmentally friendly option will always be more expensive -- but that's exactly the mindset (of the environmentalists) that I want to attack -- that we should not accept that as the bar. If we do accept that as a truism, the result is that there will always be someone more hungry or more desperate or just more greedy who will use the non-green method to get ahead. There will always be consumers poor enough or sufficiently non-rich who will not be able to spend more on the green option. There will always be countries whose governments don't really care about enforcing green rules etc. (because it helps their economy not to do so). The only alternative is for the green option to be the economic option. And once that option exists, the environmental lobbyists should absolutely evangelize it to the hilt!
If you think about it, data centers in the US must be Green.
Especially if they are built by Google, MSFT, or Apple.
We should demand that 100 percent of the anticipated max power draw of all "needed" data centers come from new construction of alternate energy sources - e.g. tidal, solar, wind, geothermal,hydro - that is literally BUILT in America to provide new power.
The days of power centers being built as if it doesn't matter that they contribute to global warming and help fund terrorists are over.
Umm.. you (we) don't need to *demand* anything here. Operational cost is the single most important metric of operating a datacenter. More so than even storage cost (which is a contributing factor to operating costs). Any company operating datacenter(s) is already looking into every manner imaginable to cut the cost of powering it. If a non-green cost is significantly cheaper, the company will simply not go green. If you tax stuff to make greenness more attractive (say a carbon tax) they will automatically shift to green sources. If the green source is cheaper to begin with, they will go green all the way.
For the environmentalists -- don't spend cycles on forcing people to adopt stuff that doesn't work for them. People in general want to do the right thing. You just have to spend your cycles on making the green thing the right thing. Make the environmentally friendly option equal to or cheaper than the non-environmentally option, and people will automatically do the right thing.
In fact, if you really want a concrete example of why this 'memo' is useless FUD, check this out: http://blogs.msdn.com/dmahugh/archive/2009/05/05/odf-spreadsheet-interoperability.aspx
So you're arguing that MS's lawyers are completely incompetent and didn't know that being incompatible was a violation of antirust law and that antitrust law doesn't mention anything about standards compliance? I think that's a naive.
Whaaa? You just wrote an entire line of BS with a straight face. Good job.
They already own BSD licensed code that works on MS Office. Next argument please!
You can't take GPLd code (or a derivative thereof) and release it under a BSD license. Next.
But it's clear an precise enough that it worked for everyone else and there are multiple working open source implementations, one of which they can literally copy and paste from and which they helped fund the creation of and probably have full rights to it even if it wasn't BSD licensed. Sorry, that argument doesn't fly either.
???
1. Get this copy-paste notion out of your head. BSD and GPL are not compatible licenses.
2. "Many implementations that do the same thing" is not the same as "all these implementations follow the ODF standard".
Then there are cases where the popular ODF implementations aren't compliant with the spec.
Example please.
Will this suffice? How about this?
Quote: "So these two ODF implementations (OpenOffice and Symphony) do not have predictable formula interoperability, regardless of where you start. And these are not obscure implementations - they are the latest released versions of the implementations from IBM and Sun, the two companies that together chair the ODF Technical Committee"
They already did. MS doesn't want a standard for interoperability. They are simply looking for any way they can be compliant but still be incompatible.
I have a simpler theory -- you don't actually know anything about the standard and are just spouting off anything that comes to your mind.
Not really, that's what reference implementations are for. If you have any doubt about how to handle this, see the reference implementations and do it that way.
Gee, that way OOXML is a brilliantly well-defined standard.
The only argument you made that has any legs is the first one regarding compliance with the spec, but only if you assume ignorance of the law (I assume you perhaps aren't that familiar with antitrust law). I assure you, while it may at times appear that all of MS's lawyers have never heard of antitrust law, that is not the case in reality.
Very bold claim there. Wanna back it up with some legalese? How about you point us to this section of antitrust law that deals with compatibility taking precedence over standards compliance?
The kicker -- this consortium (ODF Alliance) is really just coming off as some sort of FUD-monger in this (don't kid yourself -- FOSS related entities use FUD too -- ain't nobody got a monopoly on FUD). The ODF alliance can invest cycles in fixing their standard, or in fixing their own implementations - heck they can even contribute to improving the compliance of MS's ODF converters (they're open source after all). OR, they can spend cycles on FUD. For example, their point about MS's commitment to support future versions of ODF. Also, their whining about lack of 'native' support for ODF in Office 2003 (this product was released 2 years before the ODF standard was ratified, for fucks sake). Then, they linked to other FUD (claiming MS is trying to fragment ODF).
At one point, they themselves concede that they don't have their shit together when it comes to spreadsheet formulas: "Though spreadsheet formula for ODF 1.0/1.1 (the version which Microsoft claims it supports in Office 2007) are implementation-d
Nothing special at all. It's slashdot, kdawson fud, slow news day, or some combination thereof. I mean, reading the stuff on this thread, you'd think nobody ever downloaded trialware from the 'net that became full-featured on coughing up some dough. Nothing but another reason to bash MS and think that somehow that's a meaningful contribution to the world.
Yeah, you're right -- static analyzers already should (and do) catch these things. But it's still worth it to decouple the thinking (and hence the handling) of the size of the source and destination. i.e. you have that as your prime motive for banning this API, and the static analyzer as the fallback to guard against the bad habit of just passing in the exact same varabile as source size and destination size.
Remember, ultimately all of this can be defeated by a programmer who's determined to be insecure/stupid. He/she could just put in some #pragma at that statement that tells the static analyzer "this is cool -- don't throw an alert when you see it" and then pass in the same variable. i.e. this coder has gone and defeated the purpose of both the banned API list and the static analyzer. So there's no magic bullet for sure. But that doesn't mean you shouldn't make whatever improvements you can -- and this is definitely a Good Thing.