That sold linux to quite a few skeptics in our IT department, as it should.
See, it's just a matter of perspective. You keep talking about ReactOS like it's a product you can go and buy at WalMart's. It's not. It's far from being a product. From this perspective, probably even DOS would be better than ReactOS
What's so special about ReactOS is that it's one of the few open source project of cloning the NT kernel still alive, if not the only. What does this mean?
Windows will not die. If Microsoft discontinues it, the knowledge and source code of ReactOS will remain. This may not sound much, but for some it's important
Variety. ReactOS is the only non-Unix and non-completely-experimental open source system I know of. ReactOS sets a precedent (if you think this could kill ReactOS, think again. Implementing Unix on top of the NT kernel isn't that hard, and I'm about to demonstrate it)
Driver support. If you ever found yourself complaining about some hardware manufacturer only writing drivers for Windows, you'll understand how important this is
Finally, ReactOS is not a product, nor part of a product line. We aren't afraid to document how to replace or customize system components, fearing that someone will do better than us, and kill the sales of the next release
Folks who have your level of internals experience aren't working in corporate IT departments, they're at MS or IBM and/or contributing to projects like ReactOS. I'm your typical IT guy, and my example is a typical IT project. And in this project, linux put NT to shame:)
Like I said before, it's too early to talk about ReactOS in these terms - it barely runs GNU Make and the GCC toolchain, it has no networking, no exceptional scheduling algorithm, no security (if you have installed ReactOS, try "kill 1" - 1 is the kernel's PID, guess what happens), nothing of interest to anyone but us into the project. I can only guarantee that ReactOS Advanced Server (if ever) will not include Paint, nor Minesweeper, nor the latest DirectX:-) (unless Jason has other plans:-P)
The reason we don't run any Windows NT based systems in production is that the architecture is flawed. It's a desktop OS with "enterprise" features tacked on. The fundamental architecture of NT is why it sucks, in my mind.
Please, don't talk about things you don't know about. What you are commenting on is a questionable implementation, not a bad design. In fact, Windows is quite the opposite: an excellent system clogged up with poor, useless, superfluous or otherwise bad software
I have a lot of respect for these guys, kernel hacking from the ground up is tough stuff, but I'd rather see them contributing their talent to the Linux or BSD projects rather than copying a flawed architecture.
Personally, I've found Linux to suck. Really suck. I'll probably have to use it in the next years, as the last way to use a computer without selling my brain to IBM, Sun, Microsoft or Apple, but I'll never really like it. I'm a Windows guy. I've never used anything else (except trying Linux because of its supposed "coolness"), and I contribute (well... I try) to ReactOS because that's where my heart is
The "but Linux is clearly superior!" attitude doesn't cut it - you have to explain why, and without any internals programming experience (as Microsoft's user interface doesn't make any justice to the underlying system) you simply lack the knowledge to do it
Opera continues its commitment to the standards as laid out by the W3C. Opera 7.0 for Windows supports the following technologies: 128-bit encryption, TLS 1.0, SSL 2 and 3, CSS1 and CSS2, XML, HTML 4.01, HTTP 1.1, ECMAScript, JavaScript 1.3, WAP/WML and full support for DOM level 2.
Opera has finally become what Mozilla now tries desperatedly to be
weak protection of address spaces (know those little programs that can be used to read other program's text fields, indeed even password fields?),
No, this is bullshit. I hate it when someone starts talking about "inherent Windows flaws", but doesn't know what he's talking about, and nobody else either, so he won't get corrected (and I mean Windows has real flaws, only you haven't got a single one)
Do you think you are accessing the other process's virtual memory? nope, the edit box is asked to copy its text in a buffer, provided by another process. A password edit box, on the NT family, replies "no way". But maybe you don't trust Windows, so why not take care of this yourself? keywords: "AppInit_DLLs" and "subclassing". Do some research
a web browser that doubles as a full-access file manager with the ability to run programs,
wrong, again. The file manager is shell32.dll and the web browser is shdocvw.dll. What you actually mean is that shdocvw.dll is a shell32.dll user - not that bad in itself, but it's a pretty avid user, too much for its own good - something that also means that Windows doesn't necessarily require Internet Explorer (shell32.dll isn't a shdocvw.dll user). The "ability to run programs" - I think you mean the various IE flaws - is just a singularly bad case of stupid handling of MIME types
a mail client that can and will automagically open (or even run) attachments,
This is Windows, you talk about components, not applications. Here the fault is of the aforementioned browser and its flawed handling of MIME types
a scripting language so powerful that a component as central the registry can be modified with it that can be used in officially non-executable things as office documents and webpages,
VBA is not VBScript, if that's what you are saying. And VBScript and the script host aren't bad things per se. See above - the MIME type handling again
the article states: "Handwriting recognition in the Tablet PC will be a boon for Asian consumers. Chinese and Japanese are pictorial languages with thousands of characters - it is a Herculean task to input these characters into an electronic document."
Not only this is perfectly feasible, but Microsoft already has such a technology. To see it in action, install the support for Japanese on Windows (any version above NT 4 and 98 should do), and activate the Japanese input method in an Unicode-aware application (for example Opera, or NT Notepad). Open the IME pad (left-click on the red pen icon in the system tray, select the menu item), activate the hand-writing mode (click on the menu that displays the current input mode, "Soft Keyboard" by default, to get the list of modes), and experiment
Keyboard input is also possible: write the translitteration of the word, and a drop-down menu will present all the ideograms that match, and remember your choice for the future
It has to work. Currently, those applications and hardware mentioned are on the idea level.:)
Of course. But on the application side, Wine has already done most of the work. It's the driver support that is very lacking (almost non-existent, primarily because we don't have a full implementation of the registry)
It should be at least NT5, not NT4.
Of course. The informations on that page are a bit outdated, our current target is Windows 2000. Since the biggest changes between NT 4 and 5 were on the kernel side (new driver architecture, new driver model), it's another thing that will take quite a bit.
Unfortunately, we're no Linux, basically no one knows us or cares about us, and the team has as little as 4-5 active members, so things go necessarily slow:-(
My observation has been, that no one truly understands the internals of a windows system. [...]
Not meaning to spam, but it sounds like you may be interested in - and most people here could use a look at - ReactOS (it's Wine's complementary project - Wine provides the user-mode part, and we the kernel). Windows is no more a Microsoft thing only
With windows the admin's education is limited to what M$ wants them to know. Thus severly handicapping their diagnostic abilities and their intuition.
Exactly, that's the whole point. Nobody of the poeple I know in person really knows Windows, and that includes our CS lab admins. Windows admins generally don't have any knowledge of the system, so they assume that there's nothing more to Windows than what they see, they can't tell the different Windows components apart (how many times did you use the term "Win32" to mean the whole system? well, it's wrong, Win32 is just a part, and not that unreplaceable either), basically they're slaves of the machine
Learning to code (and I remind you that Windows has one of the best Perl distributions around, and that Python does OLE) is a step in the right direction, but not enough. The Microsoft documentation for low level stuff is full of half truths, silences and plain lies
If you really want to get your hands dirty and actually learn something about Windows, have a look at ReactOS (shameless self-plug;-): it's Windows, it's open source
Arrrgh. Normally I'd keep silent, but this is just too much for me. I guess it's normal to expect a good deal of uninformed or misinformed people, but not a single freaking barely accurate comment?
Let's try to explain:
The API isn't flawed: this means that no application has to be rewritten, because the flaw isn't in the API (the interface), but in the cryptographic provider that handles SSL keys (an implementation). I don't know anything about cryptography (except what private and public keys are), so don't ask me info. It's all documented, look it up.
Only IE is affected: I think because nobody knows that Windows even has a Crypto API, despite an entire Microsoft website dedicated to it.
Slashdot Mirror
See, it's just a matter of perspective. You keep talking about ReactOS like it's a product you can go and buy at WalMart's. It's not. It's far from being a product. From this perspective, probably even DOS would be better than ReactOS
What's so special about ReactOS is that it's one of the few open source project of cloning the NT kernel still alive, if not the only. What does this mean?
Finally, ReactOS is not a product, nor part of a product line. We aren't afraid to document how to replace or customize system components, fearing that someone will do better than us, and kill the sales of the next release
Like I said before, it's too early to talk about ReactOS in these terms - it barely runs GNU Make and the GCC toolchain, it has no networking, no exceptional scheduling algorithm, no security (if you have installed ReactOS, try "kill 1" - 1 is the kernel's PID, guess what happens), nothing of interest to anyone but us into the project. I can only guarantee that ReactOS Advanced Server (if ever) will not include Paint, nor Minesweeper, nor the latest DirectX :-) (unless Jason has other plans :-P)
Because it's the most realistical goal we could choose
They're abandoning the product. Not the architecture. Nor the codebase. It's not the dead-end you think it is
It's not "supposed to be", it "aims to be"
Please, don't talk about things you don't know about. What you are commenting on is a questionable implementation, not a bad design. In fact, Windows is quite the opposite: an excellent system clogged up with poor, useless, superfluous or otherwise bad software
Personally, I've found Linux to suck. Really suck. I'll probably have to use it in the next years, as the last way to use a computer without selling my brain to IBM, Sun, Microsoft or Apple, but I'll never really like it. I'm a Windows guy. I've never used anything else (except trying Linux because of its supposed "coolness"), and I contribute (well... I try) to ReactOS because that's where my heart is
The "but Linux is clearly superior!" attitude doesn't cut it - you have to explain why, and without any internals programming experience (as Microsoft's user interface doesn't make any justice to the underlying system) you simply lack the knowledge to do it
Opera 7 beta 1 is out. We need no stinking Internet Explorer anymore. And I quote:
Opera has finally become what Mozilla now tries desperatedly to be
No, this is bullshit. I hate it when someone starts talking about "inherent Windows flaws", but doesn't know what he's talking about, and nobody else either, so he won't get corrected (and I mean Windows has real flaws, only you haven't got a single one)
Do you think you are accessing the other process's virtual memory? nope, the edit box is asked to copy its text in a buffer, provided by another process. A password edit box, on the NT family, replies "no way". But maybe you don't trust Windows, so why not take care of this yourself? keywords: "AppInit_DLLs" and "subclassing". Do some research
wrong, again. The file manager is shell32.dll and the web browser is shdocvw.dll. What you actually mean is that shdocvw.dll is a shell32.dll user - not that bad in itself, but it's a pretty avid user, too much for its own good - something that also means that Windows doesn't necessarily require Internet Explorer (shell32.dll isn't a shdocvw.dll user). The "ability to run programs" - I think you mean the various IE flaws - is just a singularly bad case of stupid handling of MIME types
This is Windows, you talk about components, not applications. Here the fault is of the aforementioned browser and its flawed handling of MIME types
VBA is not VBScript, if that's what you are saying. And VBScript and the script host aren't bad things per se. See above - the MIME type handling again
Not only this is perfectly feasible, but Microsoft already has such a technology. To see it in action, install the support for Japanese on Windows (any version above NT 4 and 98 should do), and activate the Japanese input method in an Unicode-aware application (for example Opera, or NT Notepad). Open the IME pad (left-click on the red pen icon in the system tray, select the menu item), activate the hand-writing mode (click on the menu that displays the current input mode, "Soft Keyboard" by default, to get the list of modes), and experiment
Keyboard input is also possible: write the translitteration of the word, and a drop-down menu will present all the ideograms that match, and remember your choice for the future
Of course. But on the application side, Wine has already done most of the work. It's the driver support that is very lacking (almost non-existent, primarily because we don't have a full implementation of the registry)
Of course. The informations on that page are a bit outdated, our current target is Windows 2000. Since the biggest changes between NT 4 and 5 were on the kernel side (new driver architecture, new driver model), it's another thing that will take quite a bit.
Unfortunately, we're no Linux, basically no one knows us or cares about us, and the team has as little as 4-5 active members, so things go necessarily slow :-(
Time for YARP (Yet Another ReactOS Plug)!
Check.
Check. Sort of :-)
Check ;-) So, do you think that ReactOS can make it?
Not meaning to spam, but it sounds like you may be interested in - and most people here could use a look at - ReactOS (it's Wine's complementary project - Wine provides the user-mode part, and we the kernel). Windows is no more a Microsoft thing only
Exactly, that's the whole point. Nobody of the poeple I know in person really knows Windows, and that includes our CS lab admins. Windows admins generally don't have any knowledge of the system, so they assume that there's nothing more to Windows than what they see, they can't tell the different Windows components apart (how many times did you use the term "Win32" to mean the whole system? well, it's wrong, Win32 is just a part, and not that unreplaceable either), basically they're slaves of the machine
Learning to code (and I remind you that Windows has one of the best Perl distributions around, and that Python does OLE) is a step in the right direction, but not enough. The Microsoft documentation for low level stuff is full of half truths, silences and plain lies
If you really want to get your hands dirty and actually learn something about Windows, have a look at ReactOS (shameless self-plug ;-): it's Windows, it's open source
Arrrgh. Normally I'd keep silent, but this is just too much for me. I guess it's normal to expect a good deal of uninformed or misinformed people, but not a single freaking barely accurate comment?
Let's try to explain: