Druaga1 is Installing New ReactOS on 3 Computers (0.4.6)

[oldman]

I get annoyed when people say you must not test ReactOS in real hardware! I have tested ReactOS in real hardware for years. What you should not do is to run it in your every-day computer. Buy an old cheap second-hand computer to do testing with, so if something goes wrong, you do not lose anything.

I no longer have any reliable computers that I can test with, or I would still be testing. The only testing that I can do is in a virtual machine and I am not a lover of VMs. They have their advantages, like rebooting quickly, but I would much prefer to do my testing in real hardware.

[val]

VMs are good for testing only for VM targetting. Using them for testing his/her OS, one ends up with his/her OS being able to run only on VMs.
The whole idea of HV is wrong. It's a time and resource consuming waste, not giving anything useful in return. Shout out to people willing to keep doing real testing on real hardware. It's a pleasure to see that there are such. When everyone just masturbates with those frigging VMs.

[milon]

You seem to be forgetting that virtual machines:
1) provide an excellent & fast environment for developers and testers
2) provide consistent hardware to ensure the software is working correctly before being introduced to hardware bugs
3) are actually used in production as data centers etc and are actually needed

I'm not at all advocating long-term reliance on VM's, but let's also not tear down the very thing that's responsible for much of ReactOS's progress.

[dizt3mp3r]

Running in a VM 'ENSURES' that casual installers (those that don't read instructions) never wreck their main machines. It should be a policy of this forum to state this fact.

If you want to test on real hardware then of course that's up to you.

The trouble is that in MOST people's minds (not you and not the clever ones ) - they do not understand the distinction between testing and running and they see people installing on real hardware and they think it is OK to install ReactOS on their laptop for running and use now.

Personally, I would never EVER run an alpha grade o/s on my main machine, I'm not sure if that makes me one of the clever ones but we do need to get that fact over to the casual installer via the download page. The information that you should never install on 'real' hardware is still a good one but with the caveat that you can do so for testing only and with the warning that it may destroy your computer! <- that means data but it is good to have a warning that really scares.

PS. Please tell me if Val's post was aimed at me and if not I might read it.

[oldman]

PS. Please tell me if Val's post was aimed at me and if not I might read it.

It is a reply to my post above; there maybe and only maybe, a veiled hint towards your general direction, because you are an advocator of the use of VMs.

[val]

You seem to be forgetting that virtual machines:
1) provide an excellent & fast environment for developers and testers
2) provide consistent hardware to ensure the software is working correctly before being introduced to hardware bugs
3) are actually used in production as data centers etc and are actually needed

I'm not at all advocating long-term reliance on VM's, but let's also not tear down the very thing that's responsible for much of ReactOS's progress.

1) No, they don't. "Excellent" is something, that helps developers to get to their original goals (making an OS, managing real computers), not misleads them into solving unnecessary problems of adopting the OS for VMs quirks. VMs suck at real HW representation. "Fast" environment in regard to VMs is a joke. But i get what "fast" you mean. the only thing VMs make "fast", it's making a wrong impression that it really helps.
2) It's not consistent with respect to real HW. Nor it is consistent even as imaginable HW. If it were, then all VMs behave the same way. Why an OS A runs well on an emulator X and fails to do so on Y at the same time? They are so "consistent".
3) This is the example of huge wastage. This direction is disappointing and counter progressive. So many watts of power are wasted just because some web master wants "root access" to their imaginable non-existent "machine". Isolation for multiple environments in data center grade machines is needed. Providers have big iron, clients could not afford nor need such monsters. So the need for partitioning and isolation arises. And other similar scenarios. They are real needs. But the accomplishment of this is awful. this "easiest" way, let us just fool "bare metal designed OSes". OSes themsevles should have some (new) mechanisms for strong isolation, It's ok if it were "hardware assisted", meaning, some new "controllers" to help to accomplish this task would be used. It would require some changes into OS designs and HW as well. It's normal. It's a progress. Modern HV reqires changes too. But the way it's done now breaks the whole idea of OS being software managing hardware. It's an example how marketing has represented laziness as a "feature". And everybody believed that. It's a shame.

OS by definition is the software managing hardware. Everything that manages HW is OS (and FW but it's not important here). If OS is placed on top of something else, it looses its OS role and becomes a toy "for cloudy virtual vacuum machines in big guys' datacenters". Instead, HV monitors become OSes. But they are so dumb, and their only role is to serve a really stupid service - fooling formerly real OSes by exposing to them "hardware" that in fact isn't hardware. And its "consistenesy" in doing so varies heavily and depends on HV machines' bugginess and fantasy/mood of their developers. As with any software. But mostly software's purpose is useful and meaningful - do some stuff user needs. The purpose of HV is a nonsense of making non-existent HW for the real OSes fooling. This only thing by itself consumes a lot of power for nothing. Not to mention it has a bad impact on HW and OS evolution.

Mostly it's illusion that VMs help with testing. Because they drive you in not that direction you wanted to ride.
Often when doing some stuff, you think, let's make it this way first, it's easier, and even though it's not what was needed, but it's "similar", after doing this we will get more experience and start to do the real thing... And then you realize, you just wasted your time doing that different thing and now you need to wipe it all out and start that "real thing".

It is a reply to my post above; there maybe and only maybe, a veiled hint towards your general direction, because you are an advocator of the use of VMs.

yes, this is my only reason to come here - making "veiled hints" toward that weird guy.

[val]

You seem to be forgetting that virtual machines:
1) provide an excellent & fast environment for developers and testers
2) provide consistent hardware to ensure the software is working correctly before being introduced to hardware bugs
3) are actually used in production as data centers etc and are actually needed

I'm not at all advocating long-term reliance on VM's, but let's also not tear down the very thing that's responsible for much of ReactOS's progress.

1) No, they don't. "Excellent" is something, that helps developers to get to their original goals (making an OS, managing real computers), not misleads them into solving unnecessary problems of adopting the OS for VMs quirks. VMs suck at real HW representation. "Fast" environment in regard to VMs is a joke. But i get what "fast" you mean. the only thing VMs make "fast", it's making a wrong impression that it really helps.
2) It's not consistent with respect to real HW. Nor it is consistent even as imaginable HW. If it were, then all VMs would behave the same way. Why an OS A runs well on an emulator X and fails to do so on Y at the same time? They are so "consistent".
3) This is the example of huge wastage. This direction is disappointing and counter progressive. So many watts of power are wasted just because some web master wants "root access" to their imaginable non-existent "machine". Isolation for multiple environments in data center grade machines is needed. Providers have big iron, clients could not afford nor need such monsters. So the need for partitioning and isolation arises. And other similar scenarios. They are real needs. But the accomplishment of this is awful. this "easiest" way, let us just fool "bare metal designed OSes". OSes themsevles should have some (new) mechanisms for strong isolation, It's ok if it were "hardware assisted", meaning, some new "controllers" to help to accomplish this task would be used. It would require some changes into OS designs and HW as well. It's normal. It's a progress. Modern HV reqires changes too. But the way it's done now breaks the whole idea of OS being software managing hardware. It's an example how marketing has represented laziness as a "feature". And everybody believed that. It's a shame.

OS by definition is the software managing hardware. Everything that manages HW is OS (and FW but it's not important here). If OS is placed on top of something else, it looses its OS role and becomes a toy "for cloudy virtual vacuum machines in big guys' datacenters". Instead, HV monitors become OSes. But they are so dumb, and their only role is to serve a really stupid service - fooling formerly real OSes by exposing to them "hardware" that in fact isn't hardware. And its "consistenesy" in doing so varies heavily and depends on HV machines' bugginess and fantasy/mood of their developers. As with any software. But mostly software's purpose is useful and meaningful - do some stuff user needs. The purpose of HV is a nonsense of making non-existent HW for the real OSes fooling. This only thing by itself consumes a lot of power for nothing. Not to mention it has a bad impact on HW and OS evolution.

Mostly it's illusion that VMs help with testing. Because they drive you in not that direction you wanted to ride.
Often when doing some stuff, you think, let's make it this way first, it's easier, and even though it's not what was needed, but it's "similar", after doing this we will get more experience and start to do the real thing... And then you realize, you just wasted your time doing that different thing and now you need to wipe it all out and start that "real thing".

It is a reply to my post above; there maybe and only maybe, a veiled hint towards your general direction, because you are an advocator of the use of VMs.

yes, this is my only reason to come here - making "veiled hints" toward that weird guy.

[Michael Long]

If this forum had a "thanks" button then I would press it for vals last post.

But there actually is a point worth mentioning pro virtual machines: If you do low level programming in windows for some time and then you use ollydbg for the first time you get (or at least I got) the feeling "ah, finally I can see what my program is doing. That's just what I needed.". The debugging mechanisms of a virtual machine are probably similar. But hardware related debugging can be misleading indeed.

[Artras]

A nice thing is dont tell bamm it´s run of sooo many of my pc´s a help to see of wat a kind of hardware

Live CD test on a IBM X31 Type 2672-PG9 wihe dock Runs
Live CD test on a IBM T23 Type 2647-AG4 Stuck in Boot