160kbps WMA are better than 128kbps WMA, but it's no way better than what you can found on concurrent services at 128kbps.
This is a horrible, unsubstantiated conclusion. No where did those testers EVER compare 160 kbps VBR WMA9 or WMA10 to "the competition" or even AAC at 128kbps. In fact, ALL of the comparisons were done at the same bitrate, for obvious reasons (they were comparing codecs, not bitrates).
In fact, only ONE of the 5 sources you have cited even did 160 kbps tests at all, and the sample size was two orders of magnitude smaller than those for 128 kbps and 64 kbps. This renders the results nearly meaningless. (You can't draw any serious conclusions with 8 test results).
WMA plain sucks, it's only advantage is that it comes pre-installed with Windows on the largest part of all PCs.
This conclusion is also not substantiated from the evidence you cited yourself. In nearly all of the same-bitrate tests, WMA comes in decidedly mid-pack, occasionally besting everyone and once in a while slipping up. This hardly equals "sucks." "Sucks" would mean that it was consistently inferior to the competition. But this is clearly not the case if you examine the results from all of those sources you just cited.
Ms getting into the content distrobution market is especially scary. If IE and a number of other windows apps are any testament, MS may very well throw DRM out there in their next version of WMP or just autoinstall it through some undocumented API on your machine when you visit their site for support. All of a sudden, the other music companies DRM becomes invalid, and MS's rules supreme on PC's with their DRM and their music store which is the only store from which you can buy music from which'll work.
This is one of the funniest examples of FUD I have read in quite a while. It's not even worth picking apart, it's so... wrong!
i can kinda see your async point - what you're saying is the innovation is in the interface? That's fair enough. But i don't know what NT's async i/o does that select() doesn't.
Well first of all, there is a huge distinction between driver-level asynchronous I/O and user-level asynchronous I/O. select() operates at user-mode level; the kernel gives the user the illusion that things are happening asynchronously by using threads on your behalf in the kernel. Prior to 2.6, these kernel threads did in fact block for I/O operations to complete. And the reason this is bad news is that once a kernel thread starts executing in a pre-2.6 kernel, nothing can preempt it. Character drivers in 2.6 kernels now have an asynchronous API they can use for operation, which is totally new to Linux. You should be able to google for it to read about it.
How many architectures does NT run on?
Currently only 3: x86, x86-64, and IA64. Support was dropped for MIPS and Alpha due to utter lack of sales (not for any technical reason). No other architectures have been seriously entertained, primarily due to lack of potential revenue. It costs lots of money to support these platforms, just in terms of testing and maintenance; if sales don't justify them, they are dropped.
NT's kernel design doesn't look so robust anymore.
On the contrary: the kernel is very portable and robust to hardware changes. NT was the first platform demonstrated publicly running on AMD64 systems in native 64-bit mode. The biggest limit there is simply MS's resources: they decided there would be a market for AMD64 boxes, but not for NT on Playstation 2.:-)
True, Unix has had Async sockets for some time, but that hardly represents a generic asynchronous I/O model that works for ALL types of I/O. And I/O Completion Ports are such a powerful abstraction that MS holds several patents on the idea because it makes async I/O so much more efficient than in other OSes.
fully preemptible kernel with fine-grained locking: A quick search turned up this: http://citeseer.ist.psu.edu/eykholt92beyond.html
so solaris definately had it in 92, if not earlier.
There is no question that Solaris was always one of the more advanced OS kernels in the world. But in 1992, when NT beta (with its preemptible kernel intact) was released to the world, it was the ONLY such beast available to run on personal computers. And I'm sure that NT, too, had its preemptible kernel working long before the beta release in 1992. And NT had the distinct advantage of being able to run on the most popular series of computers in history, the IBM-compatible PC. It did not require Sun's latest SPARC hardware, and cost no where near Sun's $1000+ licensing costs. Most Unix snobs at the time said it couldn't be done on PC hardware, and even if it could be done, why would you want to do it? If you think doing something that people said couldn't (and shouldn't) be done isn't innovative, then I don't know what is.
support for HT: wtf? now it's innovation to support a chip's features?
Actually, yes. Because the NT kernel's design is so robust, adding support for features like "logical cpu's" and non-uniform memory architectures is relatively easy to do.
Besides, you've missed my entire point. My point is that most people around here keep trumpeting Linux as the truly "innovative" platform today, when in reality Linux is most definitely a follower. It *is* catching up quickly, though.
Could it be that those who "defend the right to innovate" are simply not particularly innovative themselves?
I'm sick of this tripe. I don't mean to jump on you alone, but I've seen way too much of this FUD parroted around Slashdot, and you're the winner of my rant.:-)
If Microsoft doesn't innovate, then why is it that the list of improvements in the Linux 2.6 kernel reads like a feature list of NT from the early 90's?
O(1) scheduler? In original NT.
Async I/O? NT 3.5's I/O Completion ports.
File-aware cache manager (vs. block-aware)? Since original NT.
Fully preemptible kernel with fine-grained locking? Again, since original NT.
In-kernel thread support? Hey, original NT.
Support for HT (logical, not physical) CPUs? Added to NT in XP (2001).
That's just comparing the kernel, and I won't even go into the features that NT has that Linux still hasn't implemented.
You probably didn't know that NT already had those features, because most people don't seem to know much about Windows beyond the GUI. They assume that what they see on the surface is all that goes on. (And don't make the mistake that the NT kernel is the only innovative part about Windows.)
My point is that you shouldn't yell about the lack of innovation in a product just because the feature you're looking for isn't there.
In the same vein... "I thought that/. users were supposed to be smart enough to figure things out for themselves by reading and experimenting rather than blathering on and on about things that they know nothing about to hords of other people that also know nothing thus starting up a shit storm of FUD like the wold has never seen"
Not when Windows is the subject. Then ignorance is quite popular here, and FUD storms abound.
Every reputable scientist agrees we're gonna run out of oil soon ('soon' in the historical sense, i.e. in time for it to be a disaster).
No! They *do* expect us to run out of oil, but they do NOT expect it to cause a disaster! The reason is basic economics. As the shortage of world oil worsens, the price of oil will increase. This will not cause crisis.
The inevitable oil shortage will cause a natural balance of resources: people who really need the oil will be willing to pay more for it. If the oil is more valuable to party A, then party A will pay a premium over party B. Party B will naturally cut back on consumption, because it is not worth it to them to pay the price that A is willing to pay. This will not cause shortages, because there will ALWAYS be enough oil for those willing to pay for it! Only price caps (which some will inevitably call for, trust me) can cause true shortages because the natural supply-demand-price balance is articifically disrupted by government meddling.
The gas shortages of 1972-1973 were a direct result of Richard Nixon's price control policy, which guaranteed that supplies would be exhausted by buyers eager to consume more at the government-mandated low price. These policies continued throughout the Ford and Carter administrations (leading to more shortages in 1979) and were only overturned by Reagan's government in 1981. There has been no shortage since then, although prices certainly fluctuate to indicate the current supply/demand situation.
But in the meantime, as oil prices go up with depleted reserves, other energy sources will naturally look more attractive in price. Right now, oil and natural gas are far and away the cheapest energy resources known. As it becomes harder and harder to extract oil from the ground (we will probably never, in fact, run completely out of oil: it will simply grow too expensive to use as our primary means of energy production), the price of oil will gradually overtake that of harnessing wind and solar energy. Currently it is simply not cost-effective to build wind generators or use solar panels: the equipment cost dwarfs the resulting energy production. One day, the reverse maybe true. Or better yet, there will be a new form of cheap energy available by some other means not yet devised.
My point is basically that people such as yourself have (incorrectly) predicted the demise of the capitalist economy since the mid-1960s. Yet each year, by virtually every statistic we measure as a society, life has gotten better despite increasing populations. The "Worldwatch Institute" is a great example of an organization that makes the same claims that you make. In the 1970s they were worried about Global Cooling (yep!), pesticides, and massive coming famines. Today it's global warming, overpopulation, and oil dependency. The issues change (because the facts inevitably prove the hack theories wrong), but the people subscribing to these theories NEVER change their pessimistic outlook, even when confronted with facts that have proven their past claims wrong.
So basically, you may feel free to continue to believe whatever you want to believe: that the world is about to collapse (despite all evidence to the contrary), or that worldwide standards of living will decline for the first time in the past 3 centuries. But those shouts will inevitably fall on deaf ears because your fellow pessimists have Cried Wolf far too many times to have any credibility left.
'Just' society philosophy
on
Vive La Loafing!
·
· Score: 2, Interesting
the goal of a just, modern society is workers who work less for more.
Hmmm... I suppose quality of life and life expectancy just aren't enough anymore, eh? That we eat more, enjoy our time off more (our current buying power is unparalleled), and live longer than any other human beings in the history of civilization is apparently not sufficient proof by your standards that the current system works.
Let's pass laws to stop the greedy bastards who are living like kings, so that we're all equal! That is a very novel and just idea (especially since we're inherently equal). Profit incentives can be replaced with state mandates! Why haven't we tried this before?
Or maybe... JUST maybe... we don't realize how good we've actually got it? Perhaps life in the idyllic past was actually more brutish and short than we can remember? And perhaps, just perhaps... the recent century's progress away from those abhorrent standards of living can be traced somewhat to the advent of industry and worldwide trade?
Nah, you're right. Life sucks, things are inevitably getting worse, and the greedy bastards are keeping us down and away from the success that we deserve because we are members of society.
Dyson invented the bagless vacuum, patented it, and approached other vacuum companies to see if they were interested.
Nope. Green and Newcombe invented the bagless vacuum in 1927. Green went on to form Rexair in 1929. Rexair vacuums have been bagless for nearly 80 years. They're now marketed under the Rainbow name but they're essentially the same product.
If Dyson claims to have invented the first vacuum that "doesn't lose suction due to clogged pores in your vacuum bag" in 1992, then I see a problem with prior art. Dyson's claim would be overly broad and clearly invalid.
More likely, Dyson's claims are much focused around the "cyclone" engine and dust-trap. Rexair's systems use the Newcombe particle separator or newer "hydrofilter" water trap.
Rexair unfortunately only sells through its distribution network (like Cutco knives). That dramatically limits its customer base, and I have no idea why. But there's always eBay!
This is a completely misleading statement. The fact that Microsoft expenses options is a *Good Thing* and is something that all corporations should be doing in the wake of recent accounting scandals.
And by saying "MS doesn't pay any corporate tax" you are insinuating that it somehow is hiding revenue, which is ludicrous. Recently, MS stock options have been "underwater" so they have not been popular to exercise. But any money that *is* spent on exercised option discounts is written off as additional employee salary expenses, which it is (the number of options purchased times the difference between the option strike price and the cost basis is added to the employee's W-2 taxable income total). MS should certainly not have to pay taxes on employee salaries: the employees already pay taxes on their salaries! Making the company pay taxes on the same money would amount to double-taxation. This is how all companies handle their options plans, assuming they are expensed on their books. If not, then investors beware...
Now, whether this deduction alone can wipe out the total taxable corporate net income of Microsoft is a different story entirely. There would have to be a LOT of options exercised to amount to that kind of money, and in recent years it just hasn't happened. Back in the late 90's, it's possible. MS net profit was much smaller back then. Today, with MS stock price stagnant for 5 years and profits stronger than ever, there is no way that options deductions could come close to offsetting their tax burden.
When you are using government IP laws to squash your competition...
I defy you to provide an example of MS exhibiting this behavior.
MS does have an impressive IP portfolio. But they have historically used this portfolio for defensive purposes only. For example, Sun sues MS over patent-infringement issues relating to the JVM. MS counter-sues with several other patent infringement issues, perhaps including for example the "Long filenames in Fat16" patent which MS holds. The resulting fray ends with a cross-licensing agreement between the two companies. Lawsuit over.
Also, as far as that stupid firing of the contractor episode is concerned, Microsoft has an unequivocal policy regarding ANY photographs on corporate grounds. Only FTE's (Full-Time Employees) are allowed to take such photographs, and there are a whole slew of restrictions on what can be done with the resulting photographs. Photographs on corporate grounds used for non-business purposes are explicitly forbidden. In this case, a "leak" of "inside information" insinuating that MS is "secretly using Apple computers" is clearly a violation of corporate policy. The guy was asking to be sacked.
Upgrading a "component so deeply entrenched into the OS" (tm) is not that simple. Actually it might break stuff, it might be a hefty download over dialup, etc.
SP2 includes a brand new version of IE with a pop-up blocker and more site-level security settings (among other things)... And Sp2 will almost certainly be delivered to most users as a Windows Update package...
Other users will pick up one of the massively distributed CDs that Sp2 will undoubtedly be shipped on... For reference, check out the press release for MS's $300 million campaign to "advertise and distribute" SP2. It appears that the death of IE in XP has been greatly exaggerated.
Last I heard, the Windows NT 5.x kernel (2000, XP, 2003) was not even endian-clean any more, let alone portable to RISC or VLIW architectures. Why do you think it's has taken Microsoft so long to port to x86-64 and Itanium?
Your sources are simply incorrect. Windows XP 64-bit edition (yes, this is a real version of Windows that ships with Itanium systems) has been running on Itanium since late 2002. XP was also, in fact, demonstrated running on AMD64 (now called X86-64) when AMD debuted its prototype hammer processor line to the public. This occurred months before Suse's linux distro was ready. (Granted, Suse's eventual release beat MS to market, albeit with poor driver support.)
The fact that NT for x86-64 has not been released yet does not mean that NT was difficult to port. NT actively runs on tens of thousands of Itanium and Itanium2 systems daily: IA64 shares almost nothing in common with x86. The hard part lies in getting hardware vendors to supply 64-bit device drivers to make sure that 64-bit Windows looks and feels like 32-bit Windows. Last I checked, nVidia was one of the few vendors that really shined in this area.
The Hardware Abstraction Layer (HAL) subsystem, which is one of the core features of the NT kernel's design from its inception, is what allows Microsoft to port NT with relatively little development effort (testing is another story). Porting NT takes two steps: First, the NT kernel itself (written in C) needs to be recompiled on the target platform. Second, a new HAL must be written for the target platform, mostly in assembly language.
The decision to drop NT support for MIPS and PowerPC was purely business-related: there simply weren't enough sales to justify the support expenses involved with maintaining another release of Windows. I suspect (although I have never heard anything like this mentioned for obvious reasons) that someday Itanium too will eventually be dropped from the NT menu as x86-64 begins to dominate the 64-bit server market.
Linux is open source. Windows is not therefore you need a debugger for Windows because you have to guess what the problem is.
LOL! Have you ever written a device driver? Ever tried to figure out kernel-mode hangs, crashes, and odd behavior (even with your OWN source code) without a kernel-mode debugger?
I swear, I think some people here think Open Source software writes itself and magically fixes its own bugs...
That's right, lib just calls link for you. It could be replaced by a batch file or a 1 line C program.
Yep. Dumpbin.exe works the same way. It just invokes link.exe/dump. The weird part is, neither of those options are specified when you do link/?. You have to know about those commands to get command-line help from them!
That toolkit is part of the (also free) Platform SDK, but you can install it separately. It includes NTSD (command-line debugger) and WinDBG (GUI debugger), and KD (the kernel debugger). NTSD and WinDBG sit on top of the same user-mode debugging engine, "dbgeng.dll". They both include really fantastic on-line help which can teach you a lot about debugging in Windows. That said, they are not for the faint-of-heart (the Visual Studio debugger is much more user-friendly). KD.exe uses the kernel-mode debugger built into every NT kernel by default. Of course, you need a second machine to use KD and a serial cable; when broken into the NT kernel debugger, the debuggee is not in control.
(Incidentally, is there a kernel-mode debugger available for Linux? Last time I checked, Linus opposed the concept very strongly, and Linux did not have one available. He called it a "crutch." Sorry, Linus. Kernel-mode device driver writers *like* their debuggers. I have to say that this could be one of several factors impeding device driver development on Linux.)
It is fairly well-known to insiders that Dave Cutler, chief software architect for Windows NT at Microsoft, approached AMD with the concept of extending the x86 instruction set for 64-bit instructions and data.
The motivation for this move was probably complicated, but Intel's slow-motion malaise regarding its IA64 strategy was no help. Microsoft needed a 64-bit platform that would gain wide acceptance before it devoted a significant amount of resources to drive Windows support on the platform to consumer-level quality.
Some even make the further claim that Cutler may have actually designed the instruction set for AMD and handed it to them intact. In other words, he approached them and said, "If you build a chip that runs this instruction set, we can guarantee NT support for it, and backwards compatibility with x86-32 will come for free."
AMD even acknowledges Dave Cutler and has a page with his information on their web site. If you do a search for articles, you'll find supposedly leaked memos mentioning builds of NT running on the new chip before it was even announced publicly (and hence before SuSe knew about it either).
Isn't it interesting that after a few days of access to the source code, exploits are appearing for obvious bugs; yet MS have had the source code available to themselves for years but still managed to neither find nor fix these same obvious problems.
And what, pray tell, are these "exploits" to which you refer? The only one I've heard of is this IE "exploit" that only successfully targets a unpatched version of IE more than 3 years old. If that's the type of "new exploit" being generated, then I'm not exactly going to bury my systems in a falloutshelter awaiting the impending doom.
Um, let me get this straight. Windows source code is making use of Windows internal APIs, and that is somehow sinister and illegal?
I was under the impression that if you're writing an operating system, you're allowed to have internal APIs hidden from public view, APIs which are not designed to be exposed to the public. As long as the code calling these APIs also lives in the operating system, there is no "improper use of private APIs". Are you saying that's incorrect, and that Microsoft now has to export every single function defined in the system?
E.g., Explorer.exe probably makes all kinds of calls into undocumented features of ntdll.dll, but you know what? The way I see things, it has every right to do so! Only if Microsoft had written their OS to allow 3rd party shell replacements would that be improper.
From my perspective, the much more important issue revolves around the presence of 3rd party competition in the un-bundled apps market (like word processors, spreadsheets, games, etc). If MS were to use OS-level internal APIs that weren't available to the competition, it would clearly be improper. This is explicitly forbidden at Microsoft.
If there is evidence that there are OS hooks built-in for something like Microsoft Money, I'd like to see it.
Microsoft applications have access to a different platform than similar applications by published by competitors.
Microsoft was guilty of this many many years ago, and was taken to court. Today, you can bet that Microsoft ensures that teams like MS Office see only the public APIs they're supposed to be using.
Does that mean they don't have an advantage? Of course they do! They can debug with full access to the Windows source code! They can phone up the developer responsible for a particular API and say, "What gives with this error code I'm seeing?" They can file bugs in the internal database when they see something is wrong, and push hard to have their bug fixed ASAP. All of these are advantages, but they are emphatically not illegal. It's called in-house development.
If you could catch a non-bundled application like Microsoft Word using undocumented or private internal APIs today, you would make big news. But until then, quit blabbing on about stuff that happened 8 years ago and has been addressed.
Inside those 37
Burst patents based on work dating back to 1984 are legal control
over not only efficient video and audio streaming, but control of just
about every media hub strategy whether it comes from Microsoft,
Sony, or Apple.
This sounds like a patent dispute, NOT source code theft. After reading about this case for the past 5 minutes, I'm willing to bet Burst.com is yet another "let's go after deep pockets with our patent portfolio because we couldn't compete with a real product" company. Eolas ring a bell?
In any case, this allegation is completely irrelevant and immaterial to the discussion at hand. Even if Microsoft infringed on this company's patents (and I'm not convinced they did), that does NOT mean it's OK for someone to steal the Windows source code.
Despite MS market share, I'd guess that there are a lot more 64-bit linux installations around than 64-bit windows.
You might be correct, but honestly both of us are just speculating. To be honest, I think neither Linux nor Windows can match the number of Solaris 64-bit installations there are in the world. But again, it would be interesting to see some data on the matter. My point was only that one can't call Linux "a much more mature platform," as the previous poster did.
I do know that HP and one or two others are shipping Itanium2 servers full-steam at the moment, despite Intel's recent 64-bit malaise. It's almost a given that all of those will be running 64-bit Windows. I've seen a demo of a HP 64-bit workstation running 64-bit Windows, and it was really nice. It even had accelerated video drivers, but I don't know what video hardware.
MS has a big disadvantage here, because they need to wait for their ISV's to produce 64-bit programs as well as drivers.
This is absolutely correct. If you have source code, you can (usually) just recompile for 64-bit user-mode applications. Otherwise you wait for an ISV to produce a binary for you. But Linux64 is in the same boat with Windows64 as far as drivers go. Arguably worse, since manufacturers have been (until now) unwilling to make their drivers open source and generally produce Linux drivers only after Windows drivers are already complete. And as we all know, the KEY to PC users' hearts is seamless hardware support!
Sure, they can create virtual instances of Windows on top of Windows, but that's not very mass market.
There are TONS of old NT4 servers sitting out there all over the world. Sysadmins are afraid to touch them because they work, and they don't want to screw something up. But they are afraid that the hardware will fail some day, and they'll be stuck looking for a system that they can slap NT4 SP6a on.
Virtual PC can take several of these servers and aggregate them ALL on a single modern box. One computer can take the place of several old servers. The newer hardware is less likely to fail (at least by MTBF numbers) and Virtual PC guarantees that you can still install NT4 SP6a on a virtual server, whereas you might not be able to do it on the latest Hyper-Threaded Dual Xeon.
Now you only have ONE physical box to administer, you only have ONE box to keep running, you can tightly control the "virtual hardware" on each PC without spending money, and you've even saved some money on your power bill in the process.
Of course windows likely will run slower since it's so optimized for the older 32bit platform.
The last time I checked, NT is built on something called a "Hardware Abstraction Layer" that made it relatively painless to port NT from MIPS to x86 and then to PowerPC. (NT was designed on MIPS R4000 machines which themselves were completely designed internally by Microsoft. This effort was deemed necessary to keep the codebase free of x86-specific assumptions and optimizations since portability was a key NT goal.) The hardest part about getting your system to run on a new 64-bit platform is getting drivers to work; generally you need lots of support from hardware vendors to accomplish this feat. Getting the OS itself to compile is the easy part.
But I doubt seriously that Windows NT is "so optimized for the older 32bit platform." The kernel is clearly portable to other architectures, and was in fact developed FIRST on a non-x86 architecture with different properties (page size, Endian-ness, etc). This leads me to believe that it is emphatically not "optimized" specifically for 32-bit x86. If you have evidence otherwise, I would like to see it.
Linux is just a much more mature platform for 64bit computers.
Much more mature? Perhaps you were unaware of Windows XP 64-bit Edition? Sure, it only runs on Itanium, but do you not honestly think that for Microsoft to have released it in early 2003 that they would probably have been working on it and testing it for at least a couple years prior to that? Also, from Microsoft's website, I notice that they have also implemented a 32-bit emulation layer for Itanium called "Windows On Windows 64" (WOW64) that lets the OS run 32-bit X86 code. Does Suse have this capability built-in?
The other issue which I pointed out earlier is the driver situation. You can't really call a product "much more mature" unless its drivers are more mature. I don't see a clear win either way at the moment.
Slashdot Mirror
This is a horrible, unsubstantiated conclusion. No where did those testers EVER compare 160 kbps VBR WMA9 or WMA10 to "the competition" or even AAC at 128kbps. In fact, ALL of the comparisons were done at the same bitrate, for obvious reasons (they were comparing codecs, not bitrates).
In fact, only ONE of the 5 sources you have cited even did 160 kbps tests at all, and the sample size was two orders of magnitude smaller than those for 128 kbps and 64 kbps. This renders the results nearly meaningless. (You can't draw any serious conclusions with 8 test results).
This conclusion is also not substantiated from the evidence you cited yourself. In nearly all of the same-bitrate tests, WMA comes in decidedly mid-pack, occasionally besting everyone and once in a while slipping up. This hardly equals "sucks." "Sucks" would mean that it was consistently inferior to the competition. But this is clearly not the case if you examine the results from all of those sources you just cited.
Well first of all, there is a huge distinction between driver-level asynchronous I/O and user-level asynchronous I/O. select() operates at user-mode level; the kernel gives the user the illusion that things are happening asynchronously by using threads on your behalf in the kernel. Prior to 2.6, these kernel threads did in fact block for I/O operations to complete. And the reason this is bad news is that once a kernel thread starts executing in a pre-2.6 kernel, nothing can preempt it. Character drivers in 2.6 kernels now have an asynchronous API they can use for operation, which is totally new to Linux. You should be able to google for it to read about it.
Currently only 3: x86, x86-64, and IA64. Support was dropped for MIPS and Alpha due to utter lack of sales (not for any technical reason). No other architectures have been seriously entertained, primarily due to lack of potential revenue. It costs lots of money to support these platforms, just in terms of testing and maintenance; if sales don't justify them, they are dropped.
On the contrary: the kernel is very portable and robust to hardware changes. NT was the first platform demonstrated publicly running on AMD64 systems in native 64-bit mode. The biggest limit there is simply MS's resources: they decided there would be a market for AMD64 boxes, but not for NT on Playstation 2. :-)
True, Unix has had Async sockets for some time, but that hardly represents a generic asynchronous I/O model that works for ALL types of I/O. And I/O Completion Ports are such a powerful abstraction that MS holds several patents on the idea because it makes async I/O so much more efficient than in other OSes.
There is no question that Solaris was always one of the more advanced OS kernels in the world. But in 1992, when NT beta (with its preemptible kernel intact) was released to the world, it was the ONLY such beast available to run on personal computers. And I'm sure that NT, too, had its preemptible kernel working long before the beta release in 1992. And NT had the distinct advantage of being able to run on the most popular series of computers in history, the IBM-compatible PC. It did not require Sun's latest SPARC hardware, and cost no where near Sun's $1000+ licensing costs. Most Unix snobs at the time said it couldn't be done on PC hardware, and even if it could be done, why would you want to do it? If you think doing something that people said couldn't (and shouldn't) be done isn't innovative, then I don't know what is.
Actually, yes. Because the NT kernel's design is so robust, adding support for features like "logical cpu's" and non-uniform memory architectures is relatively easy to do.
Besides, you've missed my entire point. My point is that most people around here keep trumpeting Linux as the truly "innovative" platform today, when in reality Linux is most definitely a follower. It *is* catching up quickly, though.
I'm sick of this tripe. I don't mean to jump on you alone, but I've seen way too much of this FUD parroted around Slashdot, and you're the winner of my rant. :-)
If Microsoft doesn't innovate, then why is it that the list of improvements in the Linux 2.6 kernel reads like a feature list of NT from the early 90's?
That's just comparing the kernel, and I won't even go into the features that NT has that Linux still hasn't implemented.
You probably didn't know that NT already had those features, because most people don't seem to know much about Windows beyond the GUI. They assume that what they see on the surface is all that goes on. (And don't make the mistake that the NT kernel is the only innovative part about Windows.)
My point is that you shouldn't yell about the lack of innovation in a product just because the feature you're looking for isn't there.
Not when Windows is the subject. Then ignorance is quite popular here, and FUD storms abound.
No! They *do* expect us to run out of oil, but they do NOT expect it to cause a disaster! The reason is basic economics. As the shortage of world oil worsens, the price of oil will increase. This will not cause crisis.
The inevitable oil shortage will cause a natural balance of resources: people who really need the oil will be willing to pay more for it. If the oil is more valuable to party A, then party A will pay a premium over party B. Party B will naturally cut back on consumption, because it is not worth it to them to pay the price that A is willing to pay. This will not cause shortages, because there will ALWAYS be enough oil for those willing to pay for it! Only price caps (which some will inevitably call for, trust me) can cause true shortages because the natural supply-demand-price balance is articifically disrupted by government meddling.
The gas shortages of 1972-1973 were a direct result of Richard Nixon's price control policy, which guaranteed that supplies would be exhausted by buyers eager to consume more at the government-mandated low price. These policies continued throughout the Ford and Carter administrations (leading to more shortages in 1979) and were only overturned by Reagan's government in 1981. There has been no shortage since then, although prices certainly fluctuate to indicate the current supply/demand situation.
But in the meantime, as oil prices go up with depleted reserves, other energy sources will naturally look more attractive in price. Right now, oil and natural gas are far and away the cheapest energy resources known. As it becomes harder and harder to extract oil from the ground (we will probably never, in fact, run completely out of oil: it will simply grow too expensive to use as our primary means of energy production), the price of oil will gradually overtake that of harnessing wind and solar energy. Currently it is simply not cost-effective to build wind generators or use solar panels: the equipment cost dwarfs the resulting energy production. One day, the reverse maybe true. Or better yet, there will be a new form of cheap energy available by some other means not yet devised.
My point is basically that people such as yourself have (incorrectly) predicted the demise of the capitalist economy since the mid-1960s. Yet each year, by virtually every statistic we measure as a society, life has gotten better despite increasing populations. The "Worldwatch Institute" is a great example of an organization that makes the same claims that you make. In the 1970s they were worried about Global Cooling (yep!), pesticides, and massive coming famines. Today it's global warming, overpopulation, and oil dependency. The issues change (because the facts inevitably prove the hack theories wrong), but the people subscribing to these theories NEVER change their pessimistic outlook, even when confronted with facts that have proven their past claims wrong.
So basically, you may feel free to continue to believe whatever you want to believe: that the world is about to collapse (despite all evidence to the contrary), or that worldwide standards of living will decline for the first time in the past 3 centuries. But those shouts will inevitably fall on deaf ears because your fellow pessimists have Cried Wolf far too many times to have any credibility left.
Hmmm... I suppose quality of life and life expectancy just aren't enough anymore, eh? That we eat more, enjoy our time off more (our current buying power is unparalleled), and live longer than any other human beings in the history of civilization is apparently not sufficient proof by your standards that the current system works.
Let's pass laws to stop the greedy bastards who are living like kings, so that we're all equal! That is a very novel and just idea (especially since we're inherently equal). Profit incentives can be replaced with state mandates! Why haven't we tried this before?
Or maybe... JUST maybe... we don't realize how good we've actually got it? Perhaps life in the idyllic past was actually more brutish and short than we can remember? And perhaps, just perhaps... the recent century's progress away from those abhorrent standards of living can be traced somewhat to the advent of industry and worldwide trade?
Nah, you're right. Life sucks, things are inevitably getting worse, and the greedy bastards are keeping us down and away from the success that we deserve because we are members of society.
Nope. Green and Newcombe invented the bagless vacuum in 1927. Green went on to form Rexair in 1929. Rexair vacuums have been bagless for nearly 80 years. They're now marketed under the Rainbow name but they're essentially the same product.
If Dyson claims to have invented the first vacuum that "doesn't lose suction due to clogged pores in your vacuum bag" in 1992, then I see a problem with prior art. Dyson's claim would be overly broad and clearly invalid.
More likely, Dyson's claims are much focused around the "cyclone" engine and dust-trap. Rexair's systems use the Newcombe particle separator or newer "hydrofilter" water trap.
Rexair unfortunately only sells through its distribution network (like Cutco knives). That dramatically limits its customer base, and I have no idea why. But there's always eBay!
This is a completely misleading statement. The fact that Microsoft expenses options is a *Good Thing* and is something that all corporations should be doing in the wake of recent accounting scandals.
And by saying "MS doesn't pay any corporate tax" you are insinuating that it somehow is hiding revenue, which is ludicrous. Recently, MS stock options have been "underwater" so they have not been popular to exercise. But any money that *is* spent on exercised option discounts is written off as additional employee salary expenses, which it is (the number of options purchased times the difference between the option strike price and the cost basis is added to the employee's W-2 taxable income total). MS should certainly not have to pay taxes on employee salaries: the employees already pay taxes on their salaries! Making the company pay taxes on the same money would amount to double-taxation. This is how all companies handle their options plans, assuming they are expensed on their books. If not, then investors beware...
Now, whether this deduction alone can wipe out the total taxable corporate net income of Microsoft is a different story entirely. There would have to be a LOT of options exercised to amount to that kind of money, and in recent years it just hasn't happened. Back in the late 90's, it's possible. MS net profit was much smaller back then. Today, with MS stock price stagnant for 5 years and profits stronger than ever, there is no way that options deductions could come close to offsetting their tax burden.
I defy you to provide an example of MS exhibiting this behavior.
MS does have an impressive IP portfolio. But they have historically used this portfolio for defensive purposes only. For example, Sun sues MS over patent-infringement issues relating to the JVM. MS counter-sues with several other patent infringement issues, perhaps including for example the "Long filenames in Fat16" patent which MS holds. The resulting fray ends with a cross-licensing agreement between the two companies. Lawsuit over.
Also, as far as that stupid firing of the contractor episode is concerned, Microsoft has an unequivocal policy regarding ANY photographs on corporate grounds. Only FTE's (Full-Time Employees) are allowed to take such photographs, and there are a whole slew of restrictions on what can be done with the resulting photographs. Photographs on corporate grounds used for non-business purposes are explicitly forbidden. In this case, a "leak" of "inside information" insinuating that MS is "secretly using Apple computers" is clearly a violation of corporate policy. The guy was asking to be sacked.
SP2 includes a brand new version of IE with a pop-up blocker and more site-level security settings (among other things)... And Sp2 will almost certainly be delivered to most users as a Windows Update package...
Other users will pick up one of the massively distributed CDs that Sp2 will undoubtedly be shipped on... For reference, check out the press release for MS's $300 million campaign to "advertise and distribute" SP2. It appears that the death of IE in XP has been greatly exaggerated.
No word yet about Win2k.
Your sources are simply incorrect. Windows XP 64-bit edition (yes, this is a real version of Windows that ships with Itanium systems) has been running on Itanium since late 2002. XP was also, in fact, demonstrated running on AMD64 (now called X86-64) when AMD debuted its prototype hammer processor line to the public. This occurred months before Suse's linux distro was ready. (Granted, Suse's eventual release beat MS to market, albeit with poor driver support.)
The fact that NT for x86-64 has not been released yet does not mean that NT was difficult to port. NT actively runs on tens of thousands of Itanium and Itanium2 systems daily: IA64 shares almost nothing in common with x86. The hard part lies in getting hardware vendors to supply 64-bit device drivers to make sure that 64-bit Windows looks and feels like 32-bit Windows. Last I checked, nVidia was one of the few vendors that really shined in this area.
The Hardware Abstraction Layer (HAL) subsystem, which is one of the core features of the NT kernel's design from its inception, is what allows Microsoft to port NT with relatively little development effort (testing is another story). Porting NT takes two steps: First, the NT kernel itself (written in C) needs to be recompiled on the target platform. Second, a new HAL must be written for the target platform, mostly in assembly language.
The decision to drop NT support for MIPS and PowerPC was purely business-related: there simply weren't enough sales to justify the support expenses involved with maintaining another release of Windows. I suspect (although I have never heard anything like this mentioned for obvious reasons) that someday Itanium too will eventually be dropped from the NT menu as x86-64 begins to dominate the 64-bit server market.
LOL! Have you ever written a device driver? Ever tried to figure out kernel-mode hangs, crashes, and odd behavior (even with your OWN source code) without a kernel-mode debugger?
I swear, I think some people here think Open Source software writes itself and magically fixes its own bugs...
Yep. Dumpbin.exe works the same way. It just invokes link.exe /dump. The weird part is, neither of those options are specified when you do link /?. You have to know about those commands to get command-line help from them!
Ask and ye shall receive:
Microsoft Debugging Tools for Windows
That toolkit is part of the (also free) Platform SDK, but you can install it separately. It includes NTSD (command-line debugger) and WinDBG (GUI debugger), and KD (the kernel debugger). NTSD and WinDBG sit on top of the same user-mode debugging engine, "dbgeng.dll". They both include really fantastic on-line help which can teach you a lot about debugging in Windows. That said, they are not for the faint-of-heart (the Visual Studio debugger is much more user-friendly). KD.exe uses the kernel-mode debugger built into every NT kernel by default. Of course, you need a second machine to use KD and a serial cable; when broken into the NT kernel debugger, the debuggee is not in control.
(Incidentally, is there a kernel-mode debugger available for Linux? Last time I checked, Linus opposed the concept very strongly, and Linux did not have one available. He called it a "crutch." Sorry, Linus. Kernel-mode device driver writers *like* their debuggers. I have to say that this could be one of several factors impeding device driver development on Linux.)
Hmm... and this is the web site's fault? Sounds like your browser might not be very robust to me...
It is fairly well-known to insiders that Dave Cutler, chief software architect for Windows NT at Microsoft, approached AMD with the concept of extending the x86 instruction set for 64-bit instructions and data.
The motivation for this move was probably complicated, but Intel's slow-motion malaise regarding its IA64 strategy was no help. Microsoft needed a 64-bit platform that would gain wide acceptance before it devoted a significant amount of resources to drive Windows support on the platform to consumer-level quality.
Some even make the further claim that Cutler may have actually designed the instruction set for AMD and handed it to them intact. In other words, he approached them and said, "If you build a chip that runs this instruction set, we can guarantee NT support for it, and backwards compatibility with x86-32 will come for free."
AMD even acknowledges Dave Cutler and has a page with his information on their web site. If you do a search for articles, you'll find supposedly leaked memos mentioning builds of NT running on the new chip before it was even announced publicly (and hence before SuSe knew about it either).
You be the judge.
And what, pray tell, are these "exploits" to which you refer? The only one I've heard of is this IE "exploit" that only successfully targets a unpatched version of IE more than 3 years old. If that's the type of "new exploit" being generated, then I'm not exactly going to bury my systems in a falloutshelter awaiting the impending doom.
Um, let me get this straight. Windows source code is making use of Windows internal APIs, and that is somehow sinister and illegal?
I was under the impression that if you're writing an operating system, you're allowed to have internal APIs hidden from public view, APIs which are not designed to be exposed to the public. As long as the code calling these APIs also lives in the operating system, there is no "improper use of private APIs". Are you saying that's incorrect, and that Microsoft now has to export every single function defined in the system?
E.g., Explorer.exe probably makes all kinds of calls into undocumented features of ntdll.dll, but you know what? The way I see things, it has every right to do so! Only if Microsoft had written their OS to allow 3rd party shell replacements would that be improper.
From my perspective, the much more important issue revolves around the presence of 3rd party competition in the un-bundled apps market (like word processors, spreadsheets, games, etc). If MS were to use OS-level internal APIs that weren't available to the competition, it would clearly be improper. This is explicitly forbidden at Microsoft.
If there is evidence that there are OS hooks built-in for something like Microsoft Money, I'd like to see it.
Microsoft was guilty of this many many years ago, and was taken to court. Today, you can bet that Microsoft ensures that teams like MS Office see only the public APIs they're supposed to be using.
Does that mean they don't have an advantage? Of course they do! They can debug with full access to the Windows source code! They can phone up the developer responsible for a particular API and say, "What gives with this error code I'm seeing?" They can file bugs in the internal database when they see something is wrong, and push hard to have their bug fixed ASAP. All of these are advantages, but they are emphatically not illegal. It's called in-house development.
If you could catch a non-bundled application like Microsoft Word using undocumented or private internal APIs today, you would make big news. But until then, quit blabbing on about stuff that happened 8 years ago and has been addressed.
From the article:
This sounds like a patent dispute, NOT source code theft. After reading about this case for the past 5 minutes, I'm willing to bet Burst.com is yet another "let's go after deep pockets with our patent portfolio because we couldn't compete with a real product" company. Eolas ring a bell?
In any case, this allegation is completely irrelevant and immaterial to the discussion at hand. Even if Microsoft infringed on this company's patents (and I'm not convinced they did), that does NOT mean it's OK for someone to steal the Windows source code.
You might be correct, but honestly both of us are just speculating. To be honest, I think neither Linux nor Windows can match the number of Solaris 64-bit installations there are in the world. But again, it would be interesting to see some data on the matter. My point was only that one can't call Linux "a much more mature platform," as the previous poster did.
I do know that HP and one or two others are shipping Itanium2 servers full-steam at the moment, despite Intel's recent 64-bit malaise. It's almost a given that all of those will be running 64-bit Windows. I've seen a demo of a HP 64-bit workstation running 64-bit Windows, and it was really nice. It even had accelerated video drivers, but I don't know what video hardware.
This is absolutely correct. If you have source code, you can (usually) just recompile for 64-bit user-mode applications. Otherwise you wait for an ISV to produce a binary for you. But Linux64 is in the same boat with Windows64 as far as drivers go. Arguably worse, since manufacturers have been (until now) unwilling to make their drivers open source and generally produce Linux drivers only after Windows drivers are already complete. And as we all know, the KEY to PC users' hearts is seamless hardware support!
There are TONS of old NT4 servers sitting out there all over the world. Sysadmins are afraid to touch them because they work, and they don't want to screw something up. But they are afraid that the hardware will fail some day, and they'll be stuck looking for a system that they can slap NT4 SP6a on.
Virtual PC can take several of these servers and aggregate them ALL on a single modern box. One computer can take the place of several old servers. The newer hardware is less likely to fail (at least by MTBF numbers) and Virtual PC guarantees that you can still install NT4 SP6a on a virtual server, whereas you might not be able to do it on the latest Hyper-Threaded Dual Xeon.
Now you only have ONE physical box to administer, you only have ONE box to keep running, you can tightly control the "virtual hardware" on each PC without spending money, and you've even saved some money on your power bill in the process.
Starting to smell market potential yet?
The last time I checked, NT is built on something called a "Hardware Abstraction Layer" that made it relatively painless to port NT from MIPS to x86 and then to PowerPC. (NT was designed on MIPS R4000 machines which themselves were completely designed internally by Microsoft. This effort was deemed necessary to keep the codebase free of x86-specific assumptions and optimizations since portability was a key NT goal.) The hardest part about getting your system to run on a new 64-bit platform is getting drivers to work; generally you need lots of support from hardware vendors to accomplish this feat. Getting the OS itself to compile is the easy part.
But I doubt seriously that Windows NT is "so optimized for the older 32bit platform." The kernel is clearly portable to other architectures, and was in fact developed FIRST on a non-x86 architecture with different properties (page size, Endian-ness, etc). This leads me to believe that it is emphatically not "optimized" specifically for 32-bit x86. If you have evidence otherwise, I would like to see it.
Much more mature? Perhaps you were unaware of Windows XP 64-bit Edition? Sure, it only runs on Itanium, but do you not honestly think that for Microsoft to have released it in early 2003 that they would probably have been working on it and testing it for at least a couple years prior to that? Also, from Microsoft's website, I notice that they have also implemented a 32-bit emulation layer for Itanium called "Windows On Windows 64" (WOW64) that lets the OS run 32-bit X86 code. Does Suse have this capability built-in?
The other issue which I pointed out earlier is the driver situation. You can't really call a product "much more mature" unless its drivers are more mature. I don't see a clear win either way at the moment.