WebSite Information > Article Discussions
eComStation 2.2 Beta First Impressions
Roderick Klein:
--- Quote from: ivan on April 03, 2013, 04:13:48 pm ---Just a couple of questions based on what I see here.
First, is the emphasis now for installing on notebooks?
Second, why is Intel video given a wide screen boost and not Nvidia? Out of the several hundred machines we maintain for clients we have ONE with an Intel video - and it runs headless - while the remainder are about 60% ATI and 40% Nvidia video based. For those clients that want wide screen 1920x1200 (16/10) monitors we are scouring the second-hand sites and getting as many ATI PCIe cards as we can that are listed in the Snap readme.
As a supplementary question, did anyone ask what hardware support was actually required or is the support based on the hardware that a limited number of people have for testing? If the later is the case, did anyone consider asking for volunteers to do testing - even if it was under an NDA - and if not why not?
I would love to be able to go to our clients and say with confidence that there is now available a version of OS/2 that will install on ANY computer they would like to purchase.
--- End quote ---
To answer your question about the Panorama video wide screen enabler. Research to get Nvidia wide screen enabler to work has done. And in the test-lab it sort of worked. But we have not been able to figure what needs to be done to the Nvidia BIOS to get this work properly. Its currently on the backburner. So yes we worked on this but did not get the wide screen enabler for Nvidia to work yet duo to lack of documentation on Nvidia side partly. So its peaking at Linux code and debugging the old fashion way. This is pretty time consuming :-)
With this version that has not been an emphasis to install on notebooks. What do you base this question on ?
If you want to be beta tester please send me an email rwklein at mensys.nl. No NDA needed, its very informal. See other posting about the beta testing.
If eCS 2.2 can run on an modern PC. We hope so. We have tried to combat as many problems as possible. We tested on very modern boxes we could get our hands on.
The new DB2 server running in the Mensys office with DB2 7.2 runs on a 6 core Xeon CPU box. Just get a system with an Intel gigabit controller.
Regards,
Roderick Klein
Mensys B.V.
Roderick Klein:
Hello Eirik
I see people reporting the problems with eCS 2.2 we released.
People are free to call it anything they want. All the components included in eCS 2.2 have received internal and external testing or have been around longer
and have not shown up eCS 2.2 out of the blue. Also different versions of the DVD ISO file since january of this year have tested by other people outside of Mensys (not people even on the development tested the ISO and have been giving feedback.
In fact if people want to call eCS 2.2 beta an alpha what would the should eCS 2.1 GA product be called ? When you look at the amount of bug reports that have been found with eCS 2.1 GA version. Systems without ACPI that would crash when screen01.sys loads. That is fixed now. The current problems realy reported are down 3 most irritating issue's.
* The danis506.add seems to have 1 regression that causes older laptops not to boot, analyses is already on the way.
* The problem with the Genmac driver was because the TAG thats in ecs\inst_flg file contained the word beta. Turned out these defect has been in the
genmac2.wpi file ever since it was created.
* The defect in the USB driver.
The way Q&A work has been done at Mensys has never been realy been different for the last 10 years since I have always done this.
Regards,
Roderick Klein
Mensys B.V.
Roderick Klein:
As for Eirik his question.
The eCS 2.2 beta won't be made GA next week. The beta period will be extend the end of the third week of April (at least). That means the original time frame to release the GA of eCS 2.2 is dropped.
Roderick Klein
Mensys B.V.
Doug Bissett:
--- Quote ---The way Q&A work has been done at Mensys has never been realy been different for the last 10 years since I have always done this.
--- End quote ---
We noticed. It has always been "late", and the end result has always had more problems than a user would expect. This was not unexpected in early releases, as everybody was learning. It is becoming more irritating because the record isn't getting any better. It is still "late" and there are still more problems than expected. Some of the problems are not really unexpected, but you (or somebody in the team) knew about more than one of them, before the beta was released. That should have stopped it, or you should heave gone back to what is known to work for the majority. I would also suggest that announcements of new public betas should not take place, until you have one, in hand, that works for your testers (obviously, you need more testers, to do Alpha testing), Then, the only changes that get made, would be to correct a found problem, then the beta test starts over again. When all of your testers agree that it works as expected, then you announce a public beta, and nothing changes unless a serious problem is found.
The fact that the wrong USB drivers got included, on the first download, demonstrates that somebody lost control of the product quality, and/or nobody did proper testing of the product before it was released. Announcing it, then delaying it, demonstrates that you do not have control over the product.
It seems that you need to have a list of machines that need to be tested, including newer and older laptops. Then, you need to know who can do testing for those machines (more than one, when possible - preferably an experienced user, and somebody who is not a techie), and be sure that they test specific parts that have been changed. In many cases, the test only needs to include changing a driver (like Dani), to be sure that it still works, after somebody changes something. Once all of the testers agree that something new works, it can be inserted as a candidate for the next beta, or GA. At that point, if somebody wants to change something, they (or you) need to make a business case for it, and the testing starts over. If it passes, it goes into the next release. If not, it goes back for repair, and the testing starts all over again. As soon as a product is deemed to be stable, it gets packaged as a beta, is tested by the testers, THEN you announce a new beta, or GA, and NOTHING changes. If somebody finds a problem, the process starts again.
Once a Public beta has been announced, the next Alpha cycle starts. Any new changes go into that, not into the current beta, which gets repaired only (nothing new), and eventually becomes the next GA, after found problems are repaired, and everybody (including the person who found a problem) agrees that it works as expected.
I am not saying that EVERYTHING needs to be fixed for any specific beta, or GA. You should be able to make an exception list, with known problems, and work arounds, when possible. From that information, a user can make a more intelligent decision about whether to participate, or not. Blindly falling into a problem that can disable a NIC (even in windows), without warning, is not going to impress many people. There will, of course, always be new hardware, or somebody will introduce a new program, that will surface problems that did not get caught, but they should be pretty rare.
Pete:
Hi Roderick
Would the USB drivers be responsible for what seems a slow boot time here? - or is the new kernel involved?
The eCS logo is onscreen for a long time compared with eCS2.1 and total boot time is double eCS2.1 (Time in Minutes:Seconds):-
Boot logo on screen Boot time total
eCS 2.1 00:07 00:45
eCS 2.2 beta 00:55 01:35
Anyone else seeing longer-than-eCS2.1/eCS2.0 boot times?
I'm seeing the occasional problem of the system boots to a working Desktop but the USB mouse is totally unresponsive, the pointer on screen does not move and neither button works. The last time this happened I experimented with pulling out the usb mouse lead then plugging it back in. Hey, Presto! - a working mouse. However, this is not a good "workaround" as it involves crawling under a desk to get at the usb mouse lead.
The above is not a problem that I have seen when using Lars Erdmanns USB Controller drivers build 10.186 with IBMs USBD.SYS 10.162
Regards
Pete
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version