What was so special about Halo compared to Duke Nukem 3D?
What was so special about Duke Nukem 3D compared to Doom, Quake, or 3D Realms' own Rise of the Triad?
Halo was essentially a greatest hits album of FPSes. What set it apart was its popularity. As far as I can tell, that's what set Duke Nukem 3D apart from its peers, too.
CDMA uses the CMEA and ORYX algorithms, which are pretty weak as well, as shown in the linked papers. However, CDMA has somewhat of an advantage, because it's difficult to obtain the encrypted data stream in the first place: the nature of CDMA transmission means you can't pull a signal out of the noise unless you know the codes being used by the base station and handset.
Here are a few references from people smarter than me who do a good job of explaining the differences and why Windows is not (and never will be) Unix.
For your sake, I really hope the authors of those articles aren't smarter than you.
The first one makes these points:
1. Some Windows applications are designed with the assumption that they'll be running as administrator. But as you know, recent versions of Windows no longer log the user in as an administrator; they temporarily grant admin privileges when needed, with the user's consent, which is also how Linux and OS X desktops work. Since the release of Vista, developers have had a big incentive to write software that plays nice as a normal user: avoiding the dreaded UAC popup.
2. Windows is more popular and thus more of a target. That's true, but getting people to switch to some other system will make that one a bigger target; this isn't a point in any OS's favor.
3. The author finds chmod easier to use than the Windows file security dialog box. That's his problem.
4. The author thinks Windows defaults to world-readable and -writable files, unless you go out of your way to lock down your home directory, but that's not actually true.
The second article makes some of the same mistakes -- some of which are understandable, since it's now two major releases out of date!
1. The author thinks Windows has "only recently evolved from a single-user design to a multi-user model". This is false. The author demonstrates his ignorance again by claiming "Windows XP was the first version of Windows to reflect a serious effort to isolate users from the system" -- apparently he hadn't heard of NT 3, NT 4, or Windows 2000. After that, I have a hard time taking anything he writes seriously, but I'll press on for one more...
2. The author, for some reason, uses "monolithic" to refer to integration between different components, e.g. integrating IE into Explorer. That's actually the opposite of monolithic. While this has consequences for reliability -- a flaw in IE's rendering component becomes a flaw in every app that incorporates that component -- it has no effect on multi-user separation. (Also, this affects any system with shared components, including Linux: a flaw in libjpeg becomes a flaw in every app that links to libjpeg.)
due to the underlying fundamental flaws of the OS architecture, there will always be another hole just waiting to be exploited.
This claim is not supported by anything you've said here, or by either of the linked articles.
Windows was designed as a single-user monolithic system with no mechanism to prevent malware from accessing the full machine.
Somehow you got +1 Informative for spouting this misinformed FUD. Congratulations, you tricked a moderator.
Windows 9x was designed as a single-user system. Windows NT, however, was multiuser from the beginning, and contains security measures at a fundamental level, just like Linux, Unix, VMS, etc. And Windows 2000/XP/Vista/7 trace their lineage back to NT, not 9x.
In a monolithic system a security breach anywhere compromises the entire system. Monolithic design, core access and remote procedure calls all contribute to an easily compromised system.
You keep saying "monolithic", but I don't think you know what it means. The Linux kernel is monolithic; the NT kernel is a hybrid.
Since there is still a lot of software which requires XP mode virtualization in Windows 7 and since this mode is a huge security hole which leaves the entire monolithic OS vulnerable, we are still seeing lots of malware on Windows 7. (If you run XP in a VM on Linux, it will effectively isolate the Windows VM from the rest of the Linux machine... not so on Windows.)
Do you have a citation for that, or are you just making it up? Windows 7's XP mode runs XP in a VM, just like running XP in a VM on any other operating system.
Unix was designed as a multi-user modular system with security built into the file, data, and execution modes and this gives it a secure foundation that is difficult to penetrate. By isolating files, data, and execution permissions, Linux gives each process the permissions it needs and effectively isolates the rest of the system from malware. Even poorly written Linux software will not allow access to the core of the machine. The layers of security and modular design limit the damage.
Yes, and that's also true of Windows. Every single one of those security features you mentioned was designed into NT from the start. Did you honestly not know that?
Even if Windows was open source and people fixed a bunch of broken stuff, you would still have the problem of Windows not having a good security foundation (even forcing all Windows users out of administrator mode wouldn't help much because file access is still wide open).
"Wide open"? Have you never heard of NTFS? File security on Windows is actually far more sophisticated than on most Linux filesystems. FAT32 hasn't been the default for system partitions since Windows ME.
As of Vista and Windows 7, users are "forced" out of administrator mode by default. Just like on a typical Linux or OS X desktop, if a program needs administrator privileges, it pops up an escalation box and you have to grant permission. The most prominent difference is that you only have to click a button instead of typing your password.
Indeed. When Bank of America tried to jack up the rate on my credit card (more than double), I made phone calls and wrote letters but got nowhere. After filing one complaint on the AG's web site, however, I got a call from some important-sounding person at the bank, and they dropped my rate back down and refunded the additional charges.
Sounds like a problem with that box... have you tried the procedures mentioned here?
I admit the.NET Framework is bigger and more complicated than VBRUN600.DLL, but installation problems like that are rare. The framework is already installed on something like 90% of PCs, and nearly every box sold in the past few years will be able to run.NET 2.0 apps.
You're comparing odd bugs in Java implementations to.NET's inherent (and intended) tight coupling with Windows platform. Qualitatively different.
The biggest difference is that.NET's "inherent (and intended) tight coupling with Windows platform" is a myth. There are platform-specific libraries (e.g. for GUI), but the standardized core has no dependence on Windows, and a typical console app or network server is easily portable between.NET and Mono.
Compare with C# where your typical app, whether a GUI app or a server app, can't be ported to work with Mono without reworking loads of things.
That's true for GUI apps, if you use WPF or (to a lesser extent) WinForms rather than something like Gtk#.
But console/server apps? No way. I've written compilers, assemblers, and console-mode emulators in.NET that ran on Linux with minimal (for the emulator) or no (for the compiler and assembler) modification. The game server I'm working on now needed to be changed from a Windows service to a console daemon, but other than that, it's just as portable.
VB.Net compiled applications are many times slower than VB6 compiled applications. About 10 times slower for compute-intensive operations (where VB6 actually compares quite favorably to "manly" languages like C; only a small penalty is paid).
These benchmarks disagree: VB.NET wins some comparisons and loses some, but none of the differences are nearly as dramatic as 10x. Are you sure you're not comparing debug builds to release builds, accidentally boxing your numeric values, or using some obscure numeric type that isn't natively supported in.NET?
if you're comfortable with your end users having to download hundreds of megabytes of crap that may fail to work entirely depending on what legacy version of Windows they're running
The.NET Framework download is closer to 50 MB, and it's preinstalled on Vista and Windows 7.
Its possible for a language to make certain things a little easier, but once you reach a certain point the additions to a language are of trivial advantage to a good programmer. They may help out less experienced or talented developers who can't figure out how to do the same thing without a special language construct for it, but for the experienced they end up the same.
I disagree. Closures, for example, provide a nontrivial advantage, and not just for people who can't figure out how to do the same trickery the compiler does (create a private class, move your local variables into it, change local variable expressions to field access expressions). Doing all that stuff by hand is enough of a pain that even if you know how to do it, you won't do it, and you'll end up designing a different program.
Another example: iterators. Yes, you can write your own state machine to implement IEnumerable by hand, but it's such a pain that you'll probably choose to do something else instead, like writing a method that allocates and fills a huge array all at once (even though you might only use the first few elements). The fact that the compiler can implement the lazy-sequence pattern for you means you're free to use it more often.
Java is alive and well and still running on platforms.NET could never dream of....
Such as?
There's Mono for the iPhone and game consoles, there's the.NET Compact Framework for PDAs and phones, there's the.NET Micro Framework for embedded systems. There are platforms where Mono hasn't been ported yet and a JVM has, but any platform that can run Java apps is capable of running C# apps.
As the other response pointed out, System.IO.DriveInfo is not part of the CLI. Nevertheless, it isn't really Windows-specific: Mono's implementation on Linux returns basically the same thing as the "df" command. Calling it DriveInfo rather than MountedDeviceInfo is hardly stopping anyone from implementing it.
Meanwhile, the fact that the JVM was designed around the Java language has real consequences. Lack of pointer arithmetic makes it hard to compile C++ to the JVM. Lack of tail calls makes it hard to compile functional languages.
Serious question: What platform(s) does the CLI target? Today, in that, I can use?
Microsoft's implementation,.NET, is available for Windows (x86, x64, IA64). That's the full version. There are also watered down versions (Compact Framework, Micro Framework, XNA, Silverlight) for other platforms, but I'll ignore those.
Mono is available for Linux, OS X, iPhone, Solaris, OpenBSD/NetBSD/FreeBSD, Wii, PS3, and even Windows. Officially supported architectures are x86, x64, IA64, ARM (little-endian), PowerPC, s390, and SPARC (32). Unofficial support is also there for Alpha, MIPS, ARM (big-endian), and HPPA.
While I know that 3-D adds to the experience, for some movies, I'm getting tired of having to pay an extra $4 for the glasses *each time* - then being asked to "recycle" them afterward.
Do they demand you "recycle" the glasses? Why not keep them?
While native C/C++ can be easily ported, without a compatible CLR moving to Mac isn't that easy.
The CLR isn't the problem: Mono implements the standardized parts of.NET just fine on Linux and Mac.
The parts that are easily ported in native code are the same parts that are already portable when you write them for.NET. The problem is libraries like Windows Forms that aren't part of the standard, but those aren't part of "native C/C++" either.
You realize the "point and click" stuff is for laying out dialog boxes, right?
Writing boilerplate code to lay out controls and handle window messages wasn't some noble art that's been lost. It was low level tedium that distracted from real programming. I remember opening Petzold's Windows programming book and being horrified that the code for "Hello World" spanned several pages.
I don't know about your wages, but I get paid a fair amount for my time to write C#, and that time is a lot more productive and enjoyable thanks to such things as IDEs and component libraries.
Unfortunately, Delphi was riddled with bugs. I used Delphi for years... I definitely don't miss the unstable IDE, or spending hours tracking down some weird GUI bug only to find that it was a VCL bug. At least they provided the VCL source code so I could often fix those.
Well except for all the software written in C# to run on Mono...
And the software written in C# for.NET that runs just fine on Mono with little or no modification.
The grandparent is trolling. The UI libraries that Visual Studio encourages you to use aren't as portable as Java's, but most everything else you'll use in.NET is every bit as portable as Java. Even when it comes to UI libraries, Mono has pretty good support for WinForms, and there are truly cross-platform libraries like Gtk# you can use instead.
There's no "trick", you're done when you're done. [...] I've known women to be focused on or to neglect any particular part of the experience and be as happy as you can expect a woman to be in a state of post-coital bliss.
I think we're in agreement here. I wasn't offering a recipe for sex, I was illustrating the point that "women are capable of (and often need!) so much more than that" doesn't necessarily mean you're failing if the motion sensor only registers 15 minutes.
Slashdot Mirror
What was so special about Halo compared to Duke Nukem 3D?
What was so special about Duke Nukem 3D compared to Doom, Quake, or 3D Realms' own Rise of the Triad?
Halo was essentially a greatest hits album of FPSes. What set it apart was its popularity. As far as I can tell, that's what set Duke Nukem 3D apart from its peers, too.
CDMA uses the CMEA and ORYX algorithms, which are pretty weak as well, as shown in the linked papers. However, CDMA has somewhat of an advantage, because it's difficult to obtain the encrypted data stream in the first place: the nature of CDMA transmission means you can't pull a signal out of the noise unless you know the codes being used by the base station and handset.
Here are a few references from people smarter than me who do a good job of explaining the differences and why Windows is not (and never will be) Unix.
For your sake, I really hope the authors of those articles aren't smarter than you.
The first one makes these points:
1. Some Windows applications are designed with the assumption that they'll be running as administrator. But as you know, recent versions of Windows no longer log the user in as an administrator; they temporarily grant admin privileges when needed, with the user's consent, which is also how Linux and OS X desktops work. Since the release of Vista, developers have had a big incentive to write software that plays nice as a normal user: avoiding the dreaded UAC popup.
2. Windows is more popular and thus more of a target. That's true, but getting people to switch to some other system will make that one a bigger target; this isn't a point in any OS's favor.
3. The author finds chmod easier to use than the Windows file security dialog box. That's his problem.
4. The author thinks Windows defaults to world-readable and -writable files, unless you go out of your way to lock down your home directory, but that's not actually true.
The second article makes some of the same mistakes -- some of which are understandable, since it's now two major releases out of date!
1. The author thinks Windows has "only recently evolved from a single-user design to a multi-user model". This is false. The author demonstrates his ignorance again by claiming "Windows XP was the first version of Windows to reflect a serious effort to isolate users from the system" -- apparently he hadn't heard of NT 3, NT 4, or Windows 2000. After that, I have a hard time taking anything he writes seriously, but I'll press on for one more...
2. The author, for some reason, uses "monolithic" to refer to integration between different components, e.g. integrating IE into Explorer. That's actually the opposite of monolithic. While this has consequences for reliability -- a flaw in IE's rendering component becomes a flaw in every app that incorporates that component -- it has no effect on multi-user separation. (Also, this affects any system with shared components, including Linux: a flaw in libjpeg becomes a flaw in every app that links to libjpeg.)
due to the underlying fundamental flaws of the OS architecture, there will always be another hole just waiting to be exploited.
This claim is not supported by anything you've said here, or by either of the linked articles.
Windows was designed as a single-user monolithic system with no mechanism to prevent malware from accessing the full machine.
Somehow you got +1 Informative for spouting this misinformed FUD. Congratulations, you tricked a moderator.
Windows 9x was designed as a single-user system. Windows NT, however, was multiuser from the beginning, and contains security measures at a fundamental level, just like Linux, Unix, VMS, etc. And Windows 2000/XP/Vista/7 trace their lineage back to NT, not 9x.
In a monolithic system a security breach anywhere compromises the entire system. Monolithic design, core access and remote procedure calls all contribute to an easily compromised system.
You keep saying "monolithic", but I don't think you know what it means. The Linux kernel is monolithic; the NT kernel is a hybrid.
Since there is still a lot of software which requires XP mode virtualization in Windows 7 and since this mode is a huge security hole which leaves the entire monolithic OS vulnerable, we are still seeing lots of malware on Windows 7. (If you run XP in a VM on Linux, it will effectively isolate the Windows VM from the rest of the Linux machine... not so on Windows.)
Do you have a citation for that, or are you just making it up? Windows 7's XP mode runs XP in a VM, just like running XP in a VM on any other operating system.
Unix was designed as a multi-user modular system with security built into the file, data, and execution modes and this gives it a secure foundation that is difficult to penetrate. By isolating files, data, and execution permissions, Linux gives each process the permissions it needs and effectively isolates the rest of the system from malware. Even poorly written Linux software will not allow access to the core of the machine. The layers of security and modular design limit the damage.
Yes, and that's also true of Windows. Every single one of those security features you mentioned was designed into NT from the start. Did you honestly not know that?
I said nothing of the sort. Perhaps you meant to reply to someone else.
Even if Windows was open source and people fixed a bunch of broken stuff, you would still have the problem of Windows not having a good security foundation (even forcing all Windows users out of administrator mode wouldn't help much because file access is still wide open).
"Wide open"? Have you never heard of NTFS? File security on Windows is actually far more sophisticated than on most Linux filesystems. FAT32 hasn't been the default for system partitions since Windows ME.
As of Vista and Windows 7, users are "forced" out of administrator mode by default. Just like on a typical Linux or OS X desktop, if a program needs administrator privileges, it pops up an escalation box and you have to grant permission. The most prominent difference is that you only have to click a button instead of typing your password.
For example, if you need a piece of application software that is only written for Linux
Like what?
Programs written for one OS don't work for another OS! NEWS AT 11.
This just in: more developers (especially niche commercial ones) target the more popular OS!
Indeed. When Bank of America tried to jack up the rate on my credit card (more than double), I made phone calls and wrote letters but got nowhere. After filing one complaint on the AG's web site, however, I got a call from some important-sounding person at the bank, and they dropped my rate back down and refunded the additional charges.
Sounds like a problem with that box... have you tried the procedures mentioned here?
I admit the .NET Framework is bigger and more complicated than VBRUN600.DLL, but installation problems like that are rare. The framework is already installed on something like 90% of PCs, and nearly every box sold in the past few years will be able to run .NET 2.0 apps.
Whether the .Net framework is 50M or 100M or 200M, the potential install issues (many customers are on random variants of win2K) are terrifying.
Can you elaborate on this? I've used .NET on many systems, including Win2K, and never had a problem installing the framework.
You're comparing odd bugs in Java implementations to .NET's inherent (and intended) tight coupling with Windows platform. Qualitatively different.
The biggest difference is that .NET's "inherent (and intended) tight coupling with Windows platform" is a myth. There are platform-specific libraries (e.g. for GUI), but the standardized core has no dependence on Windows, and a typical console app or network server is easily portable between .NET and Mono.
Compare with C# where your typical app, whether a GUI app or a server app, can't be ported to work with Mono without reworking loads of things.
That's true for GUI apps, if you use WPF or (to a lesser extent) WinForms rather than something like Gtk#.
But console/server apps? No way. I've written compilers, assemblers, and console-mode emulators in .NET that ran on Linux with minimal (for the emulator) or no (for the compiler and assembler) modification. The game server I'm working on now needed to be changed from a Windows service to a console daemon, but other than that, it's just as portable.
VB.Net compiled applications are many times slower than VB6 compiled applications. About 10 times slower for compute-intensive operations (where VB6 actually compares quite favorably to "manly" languages like C; only a small penalty is paid).
These benchmarks disagree: VB.NET wins some comparisons and loses some, but none of the differences are nearly as dramatic as 10x. Are you sure you're not comparing debug builds to release builds, accidentally boxing your numeric values, or using some obscure numeric type that isn't natively supported in .NET?
if you're comfortable with your end users having to download hundreds of megabytes of crap that may fail to work entirely depending on what legacy version of Windows they're running
The .NET Framework download is closer to 50 MB, and it's preinstalled on Vista and Windows 7.
Its possible for a language to make certain things a little easier, but once you reach a certain point the additions to a language are of trivial advantage to a good programmer. They may help out less experienced or talented developers who can't figure out how to do the same thing without a special language construct for it, but for the experienced they end up the same.
I disagree. Closures, for example, provide a nontrivial advantage, and not just for people who can't figure out how to do the same trickery the compiler does (create a private class, move your local variables into it, change local variable expressions to field access expressions). Doing all that stuff by hand is enough of a pain that even if you know how to do it, you won't do it, and you'll end up designing a different program.
Another example: iterators. Yes, you can write your own state machine to implement IEnumerable by hand, but it's such a pain that you'll probably choose to do something else instead, like writing a method that allocates and fills a huge array all at once (even though you might only use the first few elements). The fact that the compiler can implement the lazy-sequence pattern for you means you're free to use it more often.
Java is alive and well and still running on platforms .NET could never dream of ....
Such as?
There's Mono for the iPhone and game consoles, there's the .NET Compact Framework for PDAs and phones, there's the .NET Micro Framework for embedded systems. There are platforms where Mono hasn't been ported yet and a JVM has, but any platform that can run Java apps is capable of running C# apps.
Not really, but the point of a standard is you don't need anyone's endorsement to implement it.
As the other response pointed out, System.IO.DriveInfo is not part of the CLI. Nevertheless, it isn't really Windows-specific: Mono's implementation on Linux returns basically the same thing as the "df" command. Calling it DriveInfo rather than MountedDeviceInfo is hardly stopping anyone from implementing it.
Meanwhile, the fact that the JVM was designed around the Java language has real consequences. Lack of pointer arithmetic makes it hard to compile C++ to the JVM. Lack of tail calls makes it hard to compile functional languages.
Serious question: What platform(s) does the CLI target? Today, in that, I can use?
Microsoft's implementation, .NET, is available for Windows (x86, x64, IA64). That's the full version. There are also watered down versions (Compact Framework, Micro Framework, XNA, Silverlight) for other platforms, but I'll ignore those.
Mono is available for Linux, OS X, iPhone, Solaris, OpenBSD/NetBSD/FreeBSD, Wii, PS3, and even Windows. Officially supported architectures are x86, x64, IA64, ARM (little-endian), PowerPC, s390, and SPARC (32). Unofficial support is also there for Alpha, MIPS, ARM (big-endian), and HPPA.
While I know that 3-D adds to the experience, for some movies, I'm getting tired of having to pay an extra $4 for the glasses *each time* - then being asked to "recycle" them afterward.
Do they demand you "recycle" the glasses? Why not keep them?
While native C/C++ can be easily ported, without a compatible CLR moving to Mac isn't that easy.
The CLR isn't the problem: Mono implements the standardized parts of .NET just fine on Linux and Mac.
The parts that are easily ported in native code are the same parts that are already portable when you write them for .NET. The problem is libraries like Windows Forms that aren't part of the standard, but those aren't part of "native C/C++" either.
You realize the "point and click" stuff is for laying out dialog boxes, right?
Writing boilerplate code to lay out controls and handle window messages wasn't some noble art that's been lost. It was low level tedium that distracted from real programming. I remember opening Petzold's Windows programming book and being horrified that the code for "Hello World" spanned several pages.
I don't know about your wages, but I get paid a fair amount for my time to write C#, and that time is a lot more productive and enjoyable thanks to such things as IDEs and component libraries.
Unfortunately, Delphi was riddled with bugs. I used Delphi for years... I definitely don't miss the unstable IDE, or spending hours tracking down some weird GUI bug only to find that it was a VCL bug. At least they provided the VCL source code so I could often fix those.
The CLI is, of course, both multi-platform and multi-language. So is the JVM, even though it was designed around the Java language.
Well except for all the software written in C# to run on Mono...
And the software written in C# for .NET that runs just fine on Mono with little or no modification.
The grandparent is trolling. The UI libraries that Visual Studio encourages you to use aren't as portable as Java's, but most everything else you'll use in .NET is every bit as portable as Java. Even when it comes to UI libraries, Mono has pretty good support for WinForms, and there are truly cross-platform libraries like Gtk# you can use instead.
There's no "trick", you're done when you're done. [...] I've known women to be focused on or to neglect any particular part of the experience and be as happy as you can expect a woman to be in a state of post-coital bliss.
I think we're in agreement here. I wasn't offering a recipe for sex, I was illustrating the point that "women are capable of (and often need!) so much more than that" doesn't necessarily mean you're failing if the motion sensor only registers 15 minutes.