To be fair, Intel was right. We didn't need it at that time for most desktop apps. They never said we will never need 64-bit processors, just there were other more pressing issues they were tackling first. Seems it paid off pretty well for them. How is AMD fairing these days? When was the last time they were competitive, or turned a profit?
Well except that EA/Origin isn't using Gabe's company, and neither is Blizzard/Activision anymore. Last thing Bethesda put on steam was Skyrim which was about a year ago.
Gabe is just scared because if/when the Microsoft App Store goes live, there will be little reason to have steam anymore. Why would you want steam on linux anyway, don't they have package repositories? You can't apt-get games on linux?
Are you kidding me? Most of the people I know heard that they can upgrade from XP, Vista, and Windows 7 to Window 8 PRO for $40, and are planning on converting all their PCs the instant it is available.
Guess we run in different crowds, cause I'm getting told this from even non-tech savvy grandmothers.
anss123 is correct, there were some GDI functions that were hardware accelerated in XP, most notably BitBlt, but there were some others. Vista created a new model, but it required that GDI be rendered to both system and video memory (Where XP rendered directly to video memory or frame buffer) and even BitBlt was software rendered. Windows 7 when coupled with a WDDM 1.1 video driver no longer requires GDI to be rendered in 2 places, and re-enables hardware acceleration on many GDI functions.
DIGI international, is that the same company that used to make the Digiboard multiport serial boards? Probably. They had some very nice hardware, but their software drivers were always pretty buggy. I remember having to dig into their binaries and patch their software, or working around certain calls to avoid the buggy functions.
Not glad to see things haven't changed in the past 15 years. How are they still around???
I don't know about that, but {$currentpopularlinuxdistro} has clearly not sang its last song. With smooth and nice {$currentversion.next}, {$app.next} and, the {$feature.next}, there's interesting times ahead for desktop Linux too.
Fixed that for you so you can reuse it for the next 10 years.
If there remains any doubt, read page 133, where it's summed up pretty much exactly the same way I said:
So the NameSpace extension decision, and it's the only thing that Novell's lawyer told you this morning that Microsoft did wrong, the only thing, the only thing he said that caused all these problems and made these products late was Mr. Gates's decision in October of '94. That's what he said. There were no other, no other acts that Microsoft committed that he said caused any delay.
Those name space extensions, the ones WordPerfect wanted to use to integrate into the File/Open dialog were the only thing that Novell claims was the reason for their product delay. Straight from Novell's lawyer.
Really, please read page 58, and 59 where they start to get into the meat of the complaint, which I will quote for you here:
WordPerfect understood the importance of integrating into the Chicago shell and the need to extend
58 Microsoft's common dialogs to provide the added functionality historically present in WordPerfect or to use the name space extension API's to extend WordPerfect's own dialogs.
Let me break that down for you a little bit. As the WordPerfect developers that you will hear from in this case will explain, WordPerfect had traditionally had a very powerful file open dialogue containing features and functionality well beyond that offered by Microsoft's Word. Within this new operating system, Windows 95, application developers had a choice to make. They could rely on the common open file dialogs provided within Windows 95, or they could create their own more powerful file open dialogue.
In either case, whichever choice they made, the name space extension API's in Windows would allow application developers to add real name spaces to whichever file open dialog was chosen.
Let's look at that in a little more detail. This is the Windows 95 common file open dialogue shown on the screen. It was pretty basic compared to what WordPerfect had done in the past. You couldn't search across different drives or folders. You could only search within a given location. WordPerfect developers had identified a long list of deficiencies with Microsoft's common file open dialogue. Here's a prototype of WordPerfect's file open dialogue.
And here, the name space API's in question were added and started to be documented in the M6 beta release as described on page 61:
The M6 Beta included partial documentation for the name space extensions in an SDK, software development kit. We talked about it. This is just a list of the API's. The actual exhibit is a much bigger document written in language
61 that only a software developer could love or understand.
Those APIs were then removed in M7, the very next milestone.
Reiterating what the "name space extensions" were about on page 64:
As you may recall, the developers at WordPerfect, later Novell, back in November of 1993, were very happy about Microsoft's decision to document the name space extensions. They liked the technology, and they determined to use it for the file open dialogs for all the parts of the PerfectOffice suite. The shared code team immediately started coding, with the expectation of receiving those extensions, and later they were coding directly to the name space extensions, as documented in the M6 Beta for Windows 95 in June of 1994.
From page 76:
Mr. Gibb will explain that the file open dialogue was critical path throughout this project. The evidence will show that Mr. Gates' decision resulted in a delay in Novell's efforts to produce a timely suite for Windows 95.
From page 120:
And here's the contract between Microsoft and WordPerfect which, of course, May 24, '94, just before Novell bought it -- so it's the contract binding on Novell as well. And the idea that Novell advocates in this case, I think, is
120 that somehow, because Microsoft in a very early version of the Beta, included the name space API's, they could never take them out. That was the deception. They've told us that these API's, these four, out of thousands, might be in the product, and then later you withdrew support for them.
... I think I've made my point. This was exactly about the File/Open dialog. Gibbs also said under oath and testimony that they could have delivered on time if they used the standard File/Open dialog, but they chose to make their own custom one.
It's not really depreciating something if during a product beta process, you create an API, then remove it before that product is released. There was no released product that had that API in it, and there should be no released products that depend on it.
I'm not sure why you think it's strange. You do realize the whole case basically revolves around the "File/Open" dialog, and that WordPerfect didn't want to use that standard one, and because Microsoft (for whatever reason) decided to not give out an API to do some things with it, they decided to write their own instead of using the default one. One middle manager's decision (that wasn't overruled by someone higher up) caused the Office Suite to be delayed by 4-6 months. Although, there is argument whether Quattro would have been ready to go at that time.
Novell's whole argument is that they were delayed in release because they CHOSE to write their own custom File/Open dialog instead of using the default one, and that lead to their demise because of timing? According to them, IF they had chosen to use the default one they would have been able to deliver on schedule. This is just bad management.
Now, the reasons behind why Microsoft stopped that particular API is in question, and their motives may not have been altruistic, but it was a frigging BETA. They explicitly state that they can/may change/remove/add APIs at any stage of the beta. Sorry, but this is a silly lawsuit and should have been thrown out before it even made it this far.
I completely agree with you, because we all know that there is only 1 guy at the FBI, and he can only do 1 thing at a time, therefore if they do this, then they can't also possibly be doing anything else.
I'll watch their stock carefully over the next few days and buy some if it drops. And the "hacker" who did this? Obviously either very young or very dumb. Fool, if you are going to write your message to the world, learn some grammar. It is "too" not "to", "surprised" not "suprised", and you should have used malicious, not maliciously. You also used commas where periods should be, and you've created numerous run-on sentences. This should pass even second grade. You fail.
Really? Because I find that our internal tools would be a bad choice. First, for internal tools, we typically aren't trying to manage customer expectations, and we all know pretty well at the start what the tools objective is. Meeting about it daily is usually a waste of time. But then again, that's our place, yours may be different.
As for as I'm concerned, Agile isn't a proven methodology. Not as far as being able to produce all the claims it makes for every project. In fact, I can say that it's proven to be false, time and time again.
That said, there are SOME projects that work well in an agile environment, and it works well in SOME environments using SOME teams. And on the other hand, there are SOME environments where it just doesn't fit at all, and SOME projects don't lend themselves very well to it, and SOME teams it's a hindrance.
I call that a huge success.
I call that one tool in a shed, not the golden swiss army/ginsu blade that does everything.
Companies would not use it if it did not provide benefit.
Companies use it MAINLY because they've hired program managers that are familiar with it, typically younger ones that want change. Change is good, as long as it provides a benefit. The company typically doesn't care so long as the work gets done in a reasonable amount of time.
That depends. If he's a programmer, and his bosses are paying him well, don't expect much, and give him as much time to do it as he wants, then HE does have it all, so long as they can keep finding business.
Slashdot Mirror
To be fair, Intel was right. We didn't need it at that time for most desktop apps. They never said we will never need 64-bit processors, just there were other more pressing issues they were tackling first. Seems it paid off pretty well for them. How is AMD fairing these days? When was the last time they were competitive, or turned a profit?
Why would I download stuff with unlimited gigabit internet? I'll just run everything including my OS and BIOS straight off the internets!
If I can't get 3 fibers to my house, 1 for my OS traffic, 1 for my swap, and 1 for my apps & data then it is totally worthless to anyone!
Well except that EA/Origin isn't using Gabe's company, and neither is Blizzard/Activision anymore. Last thing Bethesda put on steam was Skyrim which was about a year ago.
Gabe is just scared because if/when the Microsoft App Store goes live, there will be little reason to have steam anymore. Why would you want steam on linux anyway, don't they have package repositories? You can't apt-get games on linux?
Are you kidding me? Most of the people I know heard that they can upgrade from XP, Vista, and Windows 7 to Window 8 PRO for $40, and are planning on converting all their PCs the instant it is available.
Guess we run in different crowds, cause I'm getting told this from even non-tech savvy grandmothers.
I found Windows 7 to be faster on older hardware than it's previous version (Vista), does that not count?
Going back a long ways, Windows for Workgroups was faster than Windows 3.1.
anss123 is correct, there were some GDI functions that were hardware accelerated in XP, most notably BitBlt, but there were some others. Vista created a new model, but it required that GDI be rendered to both system and video memory (Where XP rendered directly to video memory or frame buffer) and even BitBlt was software rendered. Windows 7 when coupled with a WDDM 1.1 video driver no longer requires GDI to be rendered in 2 places, and re-enables hardware acceleration on many GDI functions.
http://msdn.microsoft.com/en-us/library/windows/desktop/ff729480(v=vs.85).aspx
DIGI international, is that the same company that used to make the Digiboard multiport serial boards? Probably. They had some very nice hardware, but their software drivers were always pretty buggy. I remember having to dig into their binaries and patch their software, or working around certain calls to avoid the buggy functions.
Not glad to see things haven't changed in the past 15 years. How are they still around???
I don't know about that, but {$currentpopularlinuxdistro} has clearly not sang its last song. With smooth and nice {$currentversion.next}, {$app.next} and, the {$feature.next}, there's interesting times ahead for desktop Linux too.
Fixed that for you so you can reuse it for the next 10 years.
Something like:
[regex]::split([io.file]::readAllText($fileName).ToLower(),’\W+’) | group -NoElement | sort count -desc | select -first 6
A car crash involving terrorist sharks gets classified which way?
the first rule of emule is, there is no emule anymore.
Fixed that for you
Embeded video instead of transcript is fail. Using a flash player instead of HTML5, is even more fail. Seriously?
Slashdot -- news for nerd wanna-bes from 2005.
If there remains any doubt, read page 133, where it's summed up pretty much exactly the same way I said:
So the NameSpace extension decision, and it's the only thing that Novell's lawyer told you this morning that Microsoft did wrong, the only thing, the only thing he said that caused all these problems and made these products late was Mr. Gates's decision in October of '94. That's what he said. There were no other, no other acts that Microsoft committed that he said caused any delay.
Those name space extensions, the ones WordPerfect wanted to use to integrate into the File/Open dialog were the only thing that Novell claims was the reason for their product delay. Straight from Novell's lawyer.
Really, please read page 58, and 59 where they start to get into the meat of the complaint, which I will quote for you here:
WordPerfect understood the importance of integrating into the Chicago shell and the need to extend
58
Microsoft's common dialogs to provide the added functionality historically present in WordPerfect or to use the name space extension API's to extend WordPerfect's own dialogs.
Let me break that down for you a little bit. As the WordPerfect developers that you will hear from in this case will explain, WordPerfect had traditionally had a very powerful file open dialogue containing features and functionality well beyond that offered by Microsoft's Word. Within this new operating system, Windows 95, application developers had a choice to make. They could rely on the common open file dialogs provided within Windows 95, or they could create their own more powerful file open dialogue.
In either case, whichever choice they made, the name space extension API's in Windows would allow application developers to add real name spaces to whichever file open dialog was chosen.
Let's look at that in a little more detail. This is the Windows 95 common file open dialogue shown on the screen. It was pretty basic compared to what WordPerfect had done in the past. You couldn't search across different drives or folders. You could only search within a given location. WordPerfect developers had identified a long list of deficiencies with Microsoft's common file open dialogue. Here's a prototype of WordPerfect's file open dialogue.
And here, the name space API's in question were added and started to be documented in the M6 beta release as described on page 61:
The M6 Beta included partial documentation for the name space extensions in an SDK, software development kit. We talked about it. This is just a list of the API's. The actual exhibit is a much bigger document written in language
61
that only a software developer could love or understand.
Those APIs were then removed in M7, the very next milestone.
Reiterating what the "name space extensions" were about on page 64:
As you may recall, the developers at WordPerfect, later Novell, back in November of 1993, were very happy about Microsoft's decision to document the name space extensions. They liked the technology, and they determined to use it for the file open dialogs for all the parts of the PerfectOffice suite. The shared code team immediately started coding, with the expectation of receiving those extensions, and later they were coding directly to the name space extensions, as documented in the M6 Beta for Windows 95 in June of 1994.
From page 76:
Mr. Gibb will explain that the file open dialogue was critical path throughout this project. The evidence will show that Mr. Gates' decision resulted in a delay in Novell's efforts to produce a timely suite for Windows 95.
From page 120:
And here's the contract between Microsoft and WordPerfect which, of course, May 24, '94, just before Novell bought it -- so it's the contract binding on Novell as well. And the idea that Novell advocates in this case, I think, is
120
that somehow, because Microsoft in a very early version of the Beta, included the name space API's, they could never take them out. That was the deception. They've told us that these API's, these four, out of thousands, might be in the product, and then later you withdrew support for them.
... I think I've made my point. This was exactly about the File/Open dialog. Gibbs also said under oath and testimony that they could have delivered on time if they used the standard File/Open dialog, but they chose to make their own custom one.
I could be wrong, but I'm pretty sure that Office used the standard file open dialog box.
iOS isn't considered a monopoly of OSes in the tablet space? Since when?
It's not really depreciating something if during a product beta process, you create an API, then remove it before that product is released. There was no released product that had that API in it, and there should be no released products that depend on it.
I'm not sure why you think it's strange. You do realize the whole case basically revolves around the "File/Open" dialog, and that WordPerfect didn't want to use that standard one, and because Microsoft (for whatever reason) decided to not give out an API to do some things with it, they decided to write their own instead of using the default one. One middle manager's decision (that wasn't overruled by someone higher up) caused the Office Suite to be delayed by 4-6 months. Although, there is argument whether Quattro would have been ready to go at that time.
Novell's whole argument is that they were delayed in release because they CHOSE to write their own custom File/Open dialog instead of using the default one, and that lead to their demise because of timing? According to them, IF they had chosen to use the default one they would have been able to deliver on schedule. This is just bad management.
Now, the reasons behind why Microsoft stopped that particular API is in question, and their motives may not have been altruistic, but it was a frigging BETA. They explicitly state that they can/may change/remove/add APIs at any stage of the beta. Sorry, but this is a silly lawsuit and should have been thrown out before it even made it this far.
I completely agree with you, because we all know that there is only 1 guy at the FBI, and he can only do 1 thing at a time, therefore if they do this, then they can't also possibly be doing anything else.
I'll watch their stock carefully over the next few days and buy some if it drops. And the "hacker" who did this? Obviously either very young or very dumb. Fool, if you are going to write your message to the world, learn some grammar. It is "too" not "to", "surprised" not "suprised", and you should have used malicious, not maliciously. You also used commas where periods should be, and you've created numerous run-on sentences. This should pass even second grade. You fail.
Really? Because I find that our internal tools would be a bad choice. First, for internal tools, we typically aren't trying to manage customer expectations, and we all know pretty well at the start what the tools objective is. Meeting about it daily is usually a waste of time. But then again, that's our place, yours may be different.
Probably one of the most insightful posts on the subject I've seen. Well done!
As for as I'm concerned, Agile isn't a proven methodology. Not as far as being able to produce all the claims it makes for every project. In fact, I can say that it's proven to be false, time and time again.
That said, there are SOME projects that work well in an agile environment, and it works well in SOME environments using SOME teams. And on the other hand, there are SOME environments where it just doesn't fit at all, and SOME projects don't lend themselves very well to it, and SOME teams it's a hindrance.
I call that a huge success.
I call that one tool in a shed, not the golden swiss army/ginsu blade that does everything.
Companies would not use it if it did not provide benefit.
Companies use it MAINLY because they've hired program managers that are familiar with it, typically younger ones that want change. Change is good, as long as it provides a benefit. The company typically doesn't care so long as the work gets done in a reasonable amount of time.
That depends. If he's a programmer, and his bosses are paying him well, don't expect much, and give him as much time to do it as he wants, then HE does have it all, so long as they can keep finding business.
Was hoping for a score counter...