Why Windows Vista Is Evil

[Crispy]

Well, you could try using mingw (Windows gcc port), but it may or may not work. You'd need to set it all up yourself as well.

 

I don't recommend it. VC++ really isn't that bad.

[sparhawk]

You can also try cygwin.

[OrbWeaver]

If it were my choice, I'd be working on Doom 3 and TDM in Linux, using GCC rather than Visual Studio. If anyone knows a way to compile for Winblows with GCC, I'd be forever grateful.

 

For DarkRadiant we use MinGW on Windows and GCC on Linux, both using the same set of Scons files. This means that there is no need to maintain two separate sets of make files when code is added, and it also means there is no dependency on closed-source for what is supposed to be an open-source project.

 

It was, however, a considerable amount of work to get the Scons build working on Windows with MinGW, and I suspect a similar amount of work would be required to get the main mod working in the same way. For a start, none of the Scons files for the mod have been updated because they are only used on Linux, so you would have to identify all of the new files and add them in.

[sparhawk]

If it were my choice, I'd be working on Doom 3 and TDM in Linux, using GCC rather than Visual Studio. If anyone knows a way to compile for Winblows with GCC, I'd be forever grateful.

 

Oh! I must have missed that somehow.

 

In fact, if you would build and develop on Linux this would be great! We want to port it to Linux anyway, and if you would rather work on the Linux build, then we would maintain it at the same time. I guess it would take some time until it starts to even build on Linux, but once that is done, it would definitely be an advantage.

[Crispy]

Sounds like a great idea to me, if you're willing to take it on.

[Sebultura]

Thanks to that Vista crap, I'm much more interrested into switching to Linux now.

 

Anyway there's the games matter & when I see how marketing rules the stuff, stating things like "only DirectX10" will do the job whereas Open GL can do it do, I'm a bit disgusted.

 

I'm not especially against some API like DirectX or whatever, it's just that I find it unacceptable to force people buying new operating systems / new hardware for it.

[thelvyn]

I already posted a reply about compiling on linux in this thread http://forums.thedarkmod.com/index.php?showtopic=5574&hl=

 

In short I recommended a unified build system based on bjam ( see http://www.boost.org/tools/build/v1/build_system.htm for more info )

[oDDity]

I find it hard to believe that there aren't already several viable alternatives to Windows.

The PC OS market is so big and so lucrative, it's incredibly strange that there aren't other companies busting their balls trying to get a piece of that multi-billion dollar pie.

I mean, 6 years after XP, and all MS can come up with is the same old shit with a new skin.

[sparhawk]

The major problem for an OS is software. Users usually don't buy hardware, they buy software, and the appropriate hardware for this software.

 

I bet there is only a very small number who buys a gfx card on it's own. Users buy a gfx card because it offers something that makes their apps better. As such it is no surprise that there are not more OS'es around, as it takes a LOT of time to write decent apps. And you need to convince companies why they would invest effort into writing for that OS. Linux is quite successfull already, but gamecompanies still don't really adopt it. And Linux has a much bigger head start now than other OS'es. Just as an example...

[OrbWeaver]

Yeah it's the typical chicken-and-egg situation. Nobody will invest money writing software for an OS which nobody uses, but nobody is going to buy an OS which has no software available for it.

[oDDity]

So we're stuck with Windows forever then?

[sparhawk]

No. But an OS must give the user something he needs. It depends on the parameters.

[thelvyn]

Not necessarily Linux has come a long way and is still evolving all the time. Great strides have been made and the more user friendly it gets the more users it gets. The more users the more likely vendors will target it of course.

 

It is a slow painful progress since windows is so entrenched but eventually we can only hope that Linux will be a viable alternative to windows. And the chicken and the egg syndrome is exactly the problem.

[OrbWeaver]

So we're stuck with Windows forever then?

 

It's not as bad as that -- working against the "chicken-and-egg" effect is the "snowball" effect. Gradually Linux is increasing in market share, and some commercial vendors (such as Id Software) are beginning to target it for their software and game releases. Eventually, the growth might be enough that major software manufacturers start releasing Linux versions of their software, and PC suppliers sell Linux PCs alongside their Windows offerings.

 

However this is a slow process, and requires a lot of energy and investment from its supporters in order to overcome the natural advantage that Windows has through its desktop monopoly.

[Domarius]

Also, there's the fact that an OS that has to be compatible with all the software and all the hardware is more of a mammoth task than you could comprehend...

[Nyarlathotep]

No, the software has to be compatible with the OS, not the other way round. Windows has a massive market share in consumer-level pcs (Linux and other Unix variants are beginning to dominate in server-land), and that means that consumer software has to be compatible with it to achieve any kind of significant penetration in the market. Since Windows provides only very minimal, and generally very superficial, support for any industry standards for OSes (instead preferring to release its own, incompatible, closed-source "standard"), it's made much harder for software vendors to provide any sort of reliable platform-independence--unless they built for platform-independence at the start. That's how Windows keeps its stranglehold on the masses, albeit with variations on the technique.

 

As for a Windows replacement, it is almost invariably going to be a(n open-source) Unix variant, such as Linux. That said, I would keep an eye on the progress of Coyotos. The advantages of having an inherently secure, stable, formally-verified kernel cannot be sufficiently stressed. I believe it literally has the potential (if it winds up being comparable in performance to standard monolithic kernels) to revolutionize the way we think about stability, security, and compatibility in OSes.

 

As Coyotos is a microkernel design, it is capable of dynamically swapping servers (in this usage, components normally a part of the kernel, such as the filesystem and device drivers), each of which is completely separate from each other (if one server cannot recover from a failure, it doesn't affect the stability of the rest of the OS). This means that users could swap every interface that an application sees dynamically; your Linux Coyotos kernel could instantly become a Windows-clone! Furthermore, microkernel designs in general provide much better thread support than most monolithic kernels (operating at a more fundamental level), literally to the point that the same kernel that runs efficiently on a single processor can scale up to a massively parallel system effortlessly.

 

Coyotos' first application in a consumer-level OS is undoubtedly going to be GNU Hurd, designed to be a more secure extension to Unix. However, the Coyotos team is still toying with the idea of creating its own OS to take full advantage of its uniquely secure basis.

 

I already posted a reply about compiling on linux in this thread http://forums.thedarkmod.com/index.php?showtopic=5574&hl=

 

In short I recommended a unified build system based on bjam ( see http://www.boost.org/tools/build/v1/build_system.htm for more info )

Your link is apparently broken (not permission errors, as I would have expected), but I do recall reading a thread of yours (possibly your application thread?) where you mentioned Boost. Personally, I'm fine with building in some dependencies on GCC, given that it's portable to any OS. (Although, yes, I wasn't aware that it actually HAD been ported to Winblows, I still have to deal with those damn vcproj files--at least for now.) I've never used Boost, but from what I've read of it, and more in particular, its rigorous qualification standards, I would probably vouch for its utility. However, I think it might be a little more productive consider using SDL to increase portability. SDL is designed to provide a roughly equivalent level of abstraction to DirectX in various multimedia APIs (including DirectX itself). More importantly, id itself ported Doom 3 to Linux using SDL, giving us plenty of sample code to aid us in converting over to an SDL format.

 

In fact, if you would build and develop on Linux this would be great! We want to port it to Linux anyway, and if you would rather work on the Linux build, then we would maintain it at the same time. I guess it would take some time until it starts to even build on Linux, but once that is done, it would definitely be an advantage.

I'm definitely willing to give it my best, but as I've mentioned before, my lack of experience with C++ (and therefore my experience developing on Linux) may limit my ability to succeed. Note: my lack of C++ experience isn't what is keeping me from submitting my project to you; the school project I have due in two days is. Fortunately, my spring break is next week, and I don't have any plans to be going out of town...

 

Sounds like a great idea to me, if you're willing to take it on.

Not by my lonesome, I should hope! Given that Thelyn has expressed interest in creating a Linux build for TDM, and given that he has (at least some) experience developing for the platform, I'd much prefer to work with him on making the port, even if he chooses to only take an advisory role.

 

Anyways, if I plan on trying to port TDM, I'll need try installing Gentoo again (thank FSM for the GUI beta!) or seeing if I can actually force the NVidia drivers to work on Ubuntu. Ubuntu is consistently rejecting the driver on startup, requiring me to reinstall the damn thing every fucking time, after which it will work perfectly until I have to reboot. I've never been able to get around to installing my sound card drivers!

[sparhawk]

As for a Windows replacement, it is almost invariably going to be a(n open-source) Unix variant, such as Linux. That said, I would keep an eye on the progress of Coyotos. The advantages of having an inherently secure, stable, formally-verified kernel cannot be sufficiently stressed. I believe it literally has the potential (if it winds up being comparable in performance to standard monolithic kernels) to revolutionize the way we think about stability, security, and compatibility in OSes.

 

I severly doubt that. The success of an mass market OS is not because of it's inherent stabillity or other virtues. The only thing that counts is accessabillity. If you write the "best" OS in the world, being rockstable and totally secure, it will not gain any significant market share unless it is user friendly enough that Joe average doesn't have any problems with. That's why Windows was a success. It made computers accessible without requiring to know intimidate details about computer science. Nowadays everbody whins about Windows being not stable enough and having many exploits. But people don't mind if it touches their comfort. Do you regularly change your passwords? I guess not, because it becomes inconvenient. Do you think up a new strong password for every site that you register? I doubt it. Security is disregarded when it comes down to inconvenience.

[Domarius]

No, the software has to be compatible with the OS, not the other way round.

Any new OS would have to support all the existing software if it wants to have the slightest chance at gaining some consumer support.

[Nyarlathotep]

More obvious security does, yes, but what about more transparent security features? Implemented correctly, users never need know what is being done to protect them, only that something is being done at all, for example, anti-viruses. Coyotos is being designed from the ground up to be a fully-Unix compatible kernel. The only people that ever need to worry about the implementation details of the kernel are the people who write the servers. To everyone else, including software developers, the system appears to be controlled by a monolithic kernel that happens to be unusually fault-tolerant and secure. For the ordinary user, Coyotos would just be a safer variant of GNU. Ease of use is largely irrelevant at the kernel level.

 

Furthermore, a large part of the motivation behind making Coyotos a full OS is that security can be implemented at all levels in a very transparent way--one that is actually even more secure than older methods. Anyone can break into any computer if they can log in on-site, but the most common (and most dangerous) is the sort that occurs over the internet: security exploits. The beauty of the Coyotos kernel is that they intend to formally prove that it cannot be exploited. An OS running it would be impervious to viruses, worms and trojans, and denial-of-service attacks would have a severely-restricted impact (unable to destabilize a web-server in any meaningful way, it might still prevent a server from performing its role). Individual servers or programs might still have vulnerabilities, but they cannot leak into other programs or raise privileges.

 

One interesting possibility of a ground up Coyotos OS could be an entirely persistent operating system, much like Unununium. If the power goes out while you were working on your document, no worries! It's still there, just as it was moments before power failure. Nothing is volatile; everything is persistent. Of course, not everything should be persistent, nor should persistence be strict, i.e., nothing is ever erased. Persistence would likely be limited to a subset of the OS, but the idea of being able to shutdown and restore your system in the time it takes to swap a page file, with only the need for a few cursory checks to ensure integrity is tantalizing, to say the least.

 

Any new OS would have to support all the existing software if it wants to have the slightest chance at gaining some consumer support.

That assumes that the old OS isn't depreciated, or that existing software will not be ported in sufficient numbers to mandate a changeover. While yes, either directly supporting legacy programs or easing their porting is in the OS's best interest, it's hardly necessary.

[Crispy]

The beauty of the Coyotos kernel is that they intend to formally prove that it cannot be exploited.

Sounds a bit hand-wavy to me. How do you define "exploit" in a comprehensive and formally-specified manner?

 

That assumes that the old OS isn't depreciated

Which is very likely.

 

or that existing software will not be ported in sufficient numbers to mandate a changeover.

It won't. Chicken and egg problem.

 

While yes, either directly supporting legacy programs or easing their porting is in the OS's best interest, it's hardly necessary.

IMO in the modern OS climate, supporting legacy programs at least to some degree is definitely necessary, unless you have the resources to develop every single utility application from scratch for your OS (hint: you don't).

 

However you do it, you need to make sure that there are viable alternatives to every single useful piece of software that competing OSes have. Otherwise the switching cost is too high. Linux has only really started to gain consumer acceptance recently, after projects like OpenOffice and Wine have become usable. (There's still a long way to go, but it's getting there!)

[OrbWeaver]

Not by my lonesome, I should hope! Given that Thelyn has expressed interest in creating a Linux build for TDM, and given that he has (at least some) experience developing for the platform, I'd much prefer to work with him on making the port, even if he chooses to only take an advisory role.

 

I'm interesting in a Linux build as well, given that it is my primary work and development platform. I started a thread about this very topic a couple of days ago.

[Nyarlathotep]

Not anywhere I can read yet, I presume. I would have noticed it if I could read it.

 

Sounds a bit hand-wavy to me. How do you define "exploit" in a comprehensive and formally-specified manner?

"Exploit" as in there are no security holes. You state exactly what you want the kernel to do (mostly already defined from the EROS project on which it is based), then you prove that it does exactly that--no bugs, no errors. A pure capability-based system is already proven to be inherently secure, so long as the code protecting capabilities presents no holes that may be exploited. This isn't in the least "hand-wavey." It's exactly the same principle AMD and Intel use to test their floating-point units.

 

IMO in the modern OS climate, supporting legacy programs at least to some degree is definitely necessary, unless you have the resources to develop every single utility application from scratch for your OS (hint: you don't).

I was simply pointing out his assumptions. To replace Windows (without it first becoming obsolete), you obviously must ease the process of port as much as possible. Tackling Windows is an entirely different problem from replacing another OS.

 

However you do it, you need to make sure that there are viable alternatives to every single useful piece of software that competing OSes have. Otherwise the switching cost is too high. Linux has only really started to gain consumer acceptance recently, after projects like OpenOffice and Wine have become usable. (There's still a long way to go, but it's getting there!)

WinE is only really just starting to become a viable alternative for me. DirectX support is a recent addition, and it's still very, very buggy.

[Domarius]

I was simply pointing out his assumptions. To replace Windows (without it first becoming obsolete), you obviously must ease the process of port as much as possible. Tackling Windows is an entirely different problem from replacing another OS.

My "assumptions" are based on the fact that there is only one OS to replace - Windows. What else could I be talking about?

[Crispy]

Not anywhere I can read yet, I presume.

Yeah, it's in a private forum.

"Exploit" as in there are no security holes. You state exactly what you want the kernel to do (mostly already defined from the EROS project on which it is based), then you prove that it does exactly that--no bugs, no errors. A pure capability-based system is already proven to be inherently secure, so long as the code protecting capabilities presents no holes that may be exploited. This isn't in the least "hand-wavey." It's exactly the same principle AMD and Intel use to test their floating-point units.

Now that you've elaborated, I see your point. Good. Still, you do need to think carefully about what constitutes an exploit (Windows' hook functionality, for example, is rife with "features" that are, in a very real sense, exploits - but you can also use them for good purposes as well).

 

WinE is only really just starting to become a viable alternative for me. DirectX support is a recent addition, and it's still very, very buggy.

For sure, there's still work for them to do. Non-gaming applications tend to work pretty well though, or so I've heard.

[Ishtvan]

I heard that vista didn't bother supporting any wireless network protocols prior to G. Another case of laziness, demanding people buy new hardware rather than actually supporting things people still use.