That's not an NT file-system driver, it's just a program that can read files and looks like Explorer.
A proper driver is an NT IFS (installable file-system) driver, like this one.
The reason we don't pay the dishwasher 100K per year (aside from the now exorbitant $1000 price for chicken-fried steak) is that there won't ever be a dishwashing emergency that will cost the lives of hundreds of people if not dealt with in the next 20 seconds.
Yes, but is the extra few hours of uptime per yer worth an added $960,000 per year? (more if you amortize the cost of the PC server over several years)
To get the car released from customs to do the emissions testing, a bond of 250 PERCENT OF THE PRICE OF THE CAR must be put up to ensure that you will get the emissions done. You get that money back, but who has the cash to pony up like that when you are buying a car?
A U-238 tamper surrounding a U-235 shell surrounding a deuterium/tritium core is called a boosted fission bomb. You can't get super-large fission devices, even with boosting, because as you increase the mass of uranium/plutonium, you decrease your efficiency - a lot of material is simply vaporised before it detonates.
Now, in a classic Teller-Ulam thermonuclear device, the fission trigger is physically seperated from the fusion device. In the microseconds before the blast wave from the detonating fission device reaches the fusion device (which would destroy it), the intense X-ray radiation pulse explosively collapses a container of deuterium and tritium, super-compressing it. The compression wave also sets off a second fission device inside this container which super-heats the already super-compressed hydrogen, triggering the fusion reaction. There are other designs.
IIRC, the largest nuclear bomb ever tested (a russian bomb) was a multi-stage variant of the tellar-ulam design, with 97% of the output energy produced by fusion. The comparatively low amount of fission in a thermonuke is one of the reasons they're considered 'clean' nukes.
A civil court is not a credit card company. There are a number of things a judge could do to you if you refused to pay, including garnashing your paycheque and any capital gains for the rest of your life, or until you pay off your debt, whichever comes first.
The thing is, even if a court does rule that you owe the RIAA $100 000 000, what would happen? It's not like they could ever collect. I never expect to own that much money.
They'll take everything they can, and garnish your paycheque for the rest of your life.
So basically you want NT to turn into UNIX? You're not going to see them abandoning Unicode filenames - frankly it'd be stupid - since then you loose a useful I18N feature.
NT already has a unified namespace, the object manager namespace, which the filesystem is a subset of. IIRC, the path 'C:\WINNT\' is translated into \??\C\WINNT, and \??\C is a symbolic link to \Device\Harddisk0\Parition0, translating it into \Device\Harddisk0\Parition0\WINNT internally.
NT also has the equivalent of UNIX file descriptors, HANDLEs. Instead of select, you have WaitForMultipleObjects. And unlike POSIX select which can only wait on files and sockets, you can wait on practically anything in NT: files, sockets, semaphores, events, timers, etc...
NT isn't UNIX. Don't try to use it like UNIX and you'll tear out a lot less hair.
DotGNU in the past has tried to cooperate and initiated talks in sharing resources, but this didn't go well with Mono.
I was involved in that argument. If I recall correctly, it was a Rhys Weatherly and some others demanding that the Mono be placed under the DotGNU steering committee and that everybody work on their project instead. Of course, at the time it was quite obvious that DotGNU was mostly ideologues who were obsessed with 'defeating Microsoft' through some embrace and extend tactics, whereas most of the Mono hackers were fairly pragmatic about the whole issue: 'This is pretty cool! I'd love to see an implementation of this in Linux!'. Most of the people who weren't turned off by the downright abrasiveness of Rhys were turned off by the zealous ideology.
As for bad-mouthing, the only thing the Mono FAQ says about Portable.NET as opposed to Mono is that it the runtime (and compiler) are much less tested. Ximian claims that by developing the compiler and most of the rest of Mono in C#, the whole toolchain has been given a much more rigourous workout than Portable.NET.
In fact, I'd say the badmouthing has been much more in the other direction: there used to be a page around on the DotGNU website (not sure if it's still there) badmouthing Mono. None of the claims had any substance. For example, it claimed that Mono was on shaky legal grounds with regards to hidden Microsoft patents, which may perhaps be true. However, Portable.NET/DotGNU isn't safe from those legal threats either. Further, while Mono was developed from the ECMA (and now ISO) specifications, Portable.NET was initially developed by reverse engineering Microsoft's.NET implementation (without any clean-room engineering), putting it at risk of copyright infringement claims as well as patent claims. This was also part of the reason why there was little interest from Mono in merging the class libraries.
I suspect things are probably more civil these days. Cooler heads usually prevail in the end.
As for your other claims....
#1: The compiler is written in C/C++ not C# itself, so it doesn't have the chicken or the egg problem. Mono's CVS is very difficult to get a handle of because of this. PNET's compiler is about 3x as fast as Mono's.
Mono's CVS is easy to handle. It is distributed with a partial prebuilt toolchain, that is then used to build the entire toolchain. It's all MSIL, so there are no platform portability issues. It is also standard practice to write a compiler in its own language.
#2: The topic at hand, winforms.. PNET's winforms only dependancy is X, which means their winforms work on handhelds, osx, etc. Very portable. Mono's requires Wine, not very portable to say the least.
WinForms contains a number of window-isms, which the Wine project have already implemented. Reimplementing winelib seems silly and a waste of energy. I can't imagine it'd be appreciably harder to port Mono's WinForms implementation across platforms had it been written from scratch than it would be to port winelib itself. And if winelib gets ported, people other than Mono users and developers can benefit from that work.
Slashdot Mirror
If you're going to crash, we don't want you crashing in a densly populated area.
Real actually had a beta of RealOne available for Linux. They never went with a full release, however.
I don't get the Canadian dollar comment. The dollar rising makes imported goods like the iPod cheaper not more expensive.
That's not an NT file-system driver, it's just a program that can read files and looks like Explorer. A proper driver is an NT IFS (installable file-system) driver, like this one.
Two words: Celine Dion. Muahahaha.
Or you could just use proper mapping software, like ArcIMS.
No you're not. I've got a patent on that:
Uh, poena means punishment, not penis.
You haven't seen my sink, then.
Yes, but is the extra few hours of uptime per yer worth an added $960,000 per year? (more if you amortize the cost of the PC server over several years)
No, it's O(log n). :)
They've killed Clippy.
Yes, so we also have an order of magnitude fewer people to do the work and an order of magnitude less money to spend on it.
A device that generates net work is called a 'perpetual-motion machine'. We stopped seriously trying to build those in the 19th century.
They're one of everybody's bigguest customers. =)
The manafacturer.
Now, in a classic Teller-Ulam thermonuclear device, the fission trigger is physically seperated from the fusion device. In the microseconds before the blast wave from the detonating fission device reaches the fusion device (which would destroy it), the intense X-ray radiation pulse explosively collapses a container of deuterium and tritium, super-compressing it. The compression wave also sets off a second fission device inside this container which super-heats the already super-compressed hydrogen, triggering the fusion reaction. There are other designs.
IIRC, the largest nuclear bomb ever tested (a russian bomb) was a multi-stage variant of the tellar-ulam design, with 97% of the output energy produced by fusion. The comparatively low amount of fission in a thermonuke is one of the reasons they're considered 'clean' nukes.
A civil court is not a credit card company. There are a number of things a judge could do to you if you refused to pay, including garnashing your paycheque and any capital gains for the rest of your life, or until you pay off your debt, whichever comes first.
They'll take everything they can, and garnish your paycheque for the rest of your life.
How about integrated change and version tracking?
NT already has a unified namespace, the object manager namespace, which the filesystem is a subset of. IIRC, the path 'C:\WINNT\' is translated into \??\C\WINNT, and \??\C is a symbolic link to \Device\Harddisk0\Parition0, translating it into \Device\Harddisk0\Parition0\WINNT internally.
NT also has the equivalent of UNIX file descriptors, HANDLEs. Instead of select, you have WaitForMultipleObjects. And unlike POSIX select which can only wait on files and sockets, you can wait on practically anything in NT: files, sockets, semaphores, events, timers, etc...
NT isn't UNIX. Don't try to use it like UNIX and you'll tear out a lot less hair.
I was involved in that argument. If I recall correctly, it was a Rhys Weatherly and some others demanding that the Mono be placed under the DotGNU steering committee and that everybody work on their project instead. Of course, at the time it was quite obvious that DotGNU was mostly ideologues who were obsessed with 'defeating Microsoft' through some embrace and extend tactics, whereas most of the Mono hackers were fairly pragmatic about the whole issue: 'This is pretty cool! I'd love to see an implementation of this in Linux!'. Most of the people who weren't turned off by the downright abrasiveness of Rhys were turned off by the zealous ideology.
As for bad-mouthing, the only thing the Mono FAQ says about Portable.NET as opposed to Mono is that it the runtime (and compiler) are much less tested. Ximian claims that by developing the compiler and most of the rest of Mono in C#, the whole toolchain has been given a much more rigourous workout than Portable.NET.
In fact, I'd say the badmouthing has been much more in the other direction: there used to be a page around on the DotGNU website (not sure if it's still there) badmouthing Mono. None of the claims had any substance. For example, it claimed that Mono was on shaky legal grounds with regards to hidden Microsoft patents, which may perhaps be true. However, Portable.NET/DotGNU isn't safe from those legal threats either. Further, while Mono was developed from the ECMA (and now ISO) specifications, Portable.NET was initially developed by reverse engineering Microsoft's .NET implementation (without any clean-room engineering), putting it at risk of copyright infringement claims as well as patent claims. This was also part of the reason why there was little interest from Mono in merging the class libraries.
I suspect things are probably more civil these days. Cooler heads usually prevail in the end.
As for your other claims....
#1: The compiler is written in C/C++ not C# itself, so it doesn't have the chicken or the egg problem. Mono's CVS is very difficult to get a handle of because of this. PNET's compiler is about 3x as fast as Mono's.
Mono's CVS is easy to handle. It is distributed with a partial prebuilt toolchain, that is then used to build the entire toolchain. It's all MSIL, so there are no platform portability issues. It is also standard practice to write a compiler in its own language.
#2: The topic at hand, winforms.. PNET's winforms only dependancy is X, which means their winforms work on handhelds, osx, etc. Very portable. Mono's requires Wine, not very portable to say the least.
WinForms contains a number of window-isms, which the Wine project have already implemented. Reimplementing winelib seems silly and a waste of energy. I can't imagine it'd be appreciably harder to port Mono's WinForms implementation across platforms had it been written from scratch than it would be to port winelib itself. And if winelib gets ported, people other than Mono users and developers can benefit from that work.
Anyway, just my $0.02.
...don't.
Not functional yet, but heh, every project's got to start somewhere. </shameless plug>
That's right, we usually beat them. ;)