How do things get so taken out of context?
Let me see if I may set the record straight on a number of issues:
It is a great milestone for DFSee to support GPT, but I'm still thinking how useful will be that for OS2-eCS-BlueLion installation.
Well, we
are planning GPT support in Blue Lion, and are working on that very issue
right now.
I'm guessing that it should be useful for someone to boot from USB/CD and with DFSee try to repartition and already partitioned HDD (by Windows or Linux) and resize partition to fit OS2-eCS-BlueLion. (and of course use all the great features of DFSee on a GPT drive) But once you boot the Installer will it recognize the installation partition on GPT or after installing the OS, will it boot?
That's the plan. It's a tall order, and requires a number of things to be updated, but we are working on it (really).
I was told that what we are missing is to create some GPT driver like a FLT (Filter Device Driver). Will a GPT.FLT driver will work without having UEFI support?
I don't know who told you that.
We at Arca Noae would like to thank ...., and OS/2 VOICE for its ongoing community support.
I really do not know the formal relationship between Arca Noae and OS2VOICE, I'm getting jealous about it
Martin, you
know the relationship which Arca Noae has with OS/2 VOICE. Let me run it down
once again:
- OS/2 VOICE is the single largest OS/2 community group in the world
- Arca Noae handles donations for OS/2 VOICE, as OS/2 VOICE (unlike Warpstock Corporation) has no mechanism to accept online payments
- OS/2 VOICE is a valuable resource to Arca Noae as a means of communication with the community, at large
...super special thanks to the developers that shares their software and don't hide their source code to the public.
Is this meant as some sort of a dig at those of us who are
bound by copyright and existing license not to release everything as open source?
I really get concerned about ArcaNoae's new attitude. Instead of working on their own roadmap (https://www.arcanoae.com/roadmap/), they announce a new version OS/2.
I'm sorry that our "new attitude" concerns you, Michael. Our overall roadmap does need some updating (admittedly, we spend more time developing than updating the roadmap, and often progress isn't reflected there in as timely a fashion as we'd like). However, work on Blue Lion
complements our overall goal of bringing new drivers and support for current hardware to the platform; these two concepts are not at all at odds with one another.
My drivers and software package license expires soon, nearly nothing from roadmap was realized (except of pre-beta network drivers).
Do you somehow feel like you have not received a good value for your investment? Updates to ACPI, Multimac, and USB have not been useful to you? A roadmap is just that: a plan. It's not a promise. We have made progress toward many of the goals we set before us, though not all have been realized.
If you don't feel that you have received a good value for your investment, then you should feel free not to renew your subscription. Subscriptions were never intended as "support" contributions to further our own goals, but rather reasonable fees set for the products released. We have issued several updates to various components of the subscription during the year. If you have not benefited from them, then perhaps you shouldn't renew your subscription.
Important software repositories went away from netlabs (like USB-drivers, we no have two different repos, AHCI and ACPI).
Really? How about:
http://trac.netlabs.org/acpihttp://trac.netlabs.org/ahcihttp://trac.netlabs.org/usbLars posts his USB builds to that Netlabs project as well as to Hobbes. It has been the case for some time that we have had two different branches of the USB dev tree. The only difference now is that they are maintained in two different places.
There is nobody stopping anyone from contributing to the AHCI and ACPI projects at Netlabs. Those projects are not going away. It's just so happens that the sole maintainer of them happens to be a principal in Arca Noae, so development has moved "in-house."
So if ArcaNoae suddenly decides to drop any OS/2 Activity, we have nothing in our hands.
Hmmm... An OS/2-only company dropping OS/2 activity. That doesn't sound very realistic, now does it? Again, the maintainer of these driver projects is a human, and if you look closely at the license strings contained in your drivers, you will see that David claims copyright and Arca Noae simply licenses his work. If Arca Noae were to close up shop tomorrow (which is not very likely, especially considering the considerable sum of money we recently paid to IBM), in all likelihood, David would still continue to maintain those drivers; they're not going away.
This reminds me very much of Mensys, many announcements, no substantial progress, no transparency.
Excuse me?
We are a privately-owned company. We are not required to be transparent. That said, do you not read our blog posts? Did you not see the several Warpstock and Warpstock Europe presentations which we have given? David has often shared his progress on driver development. Steven Levine has discussed at length our plans for SNAP and the immense hurdle he has before him getting the code checked into the repository (code for which Arca Noae paid a tidy sum to license). I have discussed the Package Manager (
due for release this month, free for everyone to use) and Blue Lion (which, BTW, now has a bootable image in alpha stage, with functional networking to provide across-the-LAN or across-the-WAN installation).
No substantial progress?
We have full time developers working on code - RIGHT NOW.
Bitwise is doing a much better job here, you can follow each development step easily (see Mozilla @github or vbox @ netlabs).
Do you know who provides the bulk of the financial support for Bitwise's Firefox work?
Arca Noae does. The difference is that Bitwise has a current focus on Firefox, which is fully open source, and we are working with much of IBM's code, which is not. Portions of the drivers we maintain are not open source. This isn't our fault; we're just playing within the rules set before us.
I really doubt if I still want to continue to invest money in the products of ArcaNoae.
Again, if you feel that you haven't received a good value for your investment, you shouldn't renew your subscription. It's not charity. We believe in a fair price for a reasonable service. If our service has somehow fallen short in your experience, then please accept my apologies on behalf of the entire Company, and feel free not to renew your subscription.
How about you actually let them have a chance first of all - and a deal with Big Blue is no small deal.
And you're right they're about the last devoplers, so again how about a little support first.
Thanks, Greggory, for recognizing what an herculean task this is.
Unlike Michael I am reasonably happy with my recent Arca Noae subscription - at the moment.
I have downloaded and installed updates to ACPI, AHCI, Multimac, USB, Uniaud and JFS from the driver pack and am happy with most of these updates.
Glad to hear that, Pete.
1] The JFS /AUTOCHECK:+* switch is no longer honoured. This means that it is impossible to *force* chkdsk on drives that are Dirty but marked as Clean. This had been reported by someone else and the result is *unsatisfactory* with the bug marked as Resolved:-
Resolution: won't fix
Comment: Regardless of whether you consider it a defect fix, an enhancement, or just a change in operation, this is how it works now.
I have opened a new bug about this problem and hope that Arca Noae rethink and resolve this problem. It is silly to need to boot from another device, ie CD/DVD, in order to chkdsk a Dirty but marked Clean drive.
David and I have differing views on this, but David is thoughtful and reasonable. It had not been his experience that forcing a check on an otherwise-clean-appearing volume has had any positive result. Several of us have made the case that our experience has been different.
I'm going to go out on a limb here. We have weekly staff meetings (except for this past week, due to my own inability to make the meeting). I will add this to our next meeting agenda, and we'll discuss it.
2] Since installing this JFS release my system often "loses" a drive volume at boot. I have JFS formatted volumes G: through L: with H: and L: being bootable. About 1 in 3 boots I notice that G: is not mentioned at all during the JFS chkdsk display.
Once booted I can get G: to display in the Drives folder by running LVM and then exiting using Save and Exit - with no changes made and - Voila! drive G: appears in the Drives folder.
This sounds like there is some corruption possibly fixable with a full chkdsk run after boot or a forced chkdsk as described above. I'll have a look at the ticket for this one, and see if there's anything constructive which I might be able to add.
This is clearly undesirable behaviour by the JFS driver and needs fixing.
How do I know this is related to JFS 1.09.06?
Simple: It does not happen with any earlier release of JFS.
I have reverted to the jfs installed by eCS2.2beta2 - JFS 1.09.05 - and suggest that anyone else having any form of hard drive problems with JFS 1.09.06 - whether local or usb attached - reverts to any earlier build to see if the problem(s) go away.
JFS 1.09.05 (and prior) has/have a serious and known defect which can cause complete loss of a JFS volume. While it may address the issue you are seeing above, it's a poor long-term solution, IMO.Plugging DFSee as a disk fixer when you are supplying what in my view is a dodgy filesystem driver is a bit rich ;-)
Hmmm... Dodgy filesystem driver? That's a bit "rich," now isn't it? DFSee doesn't address the issues here, and DFSee is a third-party tool. It's not like we developed DFSee at the expense of "fixing" our own software. DFSee is a multi-purpose, multi-platform tool; the only relationship between the two is that DFSee recognizes and can address certain JFS issues.
Depending on how Arca Noae resolve these problems will affect whether I stay happy with Arca Noae.
Fair enough! Let me see what we can do.
My technical opinion: Note that with '+*' you can't force anymore any clean-marked volume being checked at all, regardless if it's dirty or not.
When a dirty boot volume is marked clean, it's time to boot from another volume and perform the chkdsk from there. If that would happen for other volumes, you have now also to boot to another volume for that. Is that really that important? How many times happened that for you?
This is an excellent point, worth making, Andreas; thanks for stating it so succinctly.
Forcing a check on a clean volume is really a shortcut to deal with the underlying problem. There is no substitute for a good maintenance partition or rescue system (we are planning a robust rescue & recovery environment for Blue Lion, BTW, with a reasonable set of tools, networking support, and the ability to really fix things on the live system, so that even if a serious problem makes it impossible to boot from a maintenance partition, the user has a decent chance of getting up and running again, just from a CD or USB boot).
2] Since installing this JFS release my system often "loses" a drive volume at boot. I have JFS formatted volumes G: through L: with H: and L: being bootable. About 1 in 3 boots I notice that G: is not mentioned at all during the JFS chkdsk display.
Once booted I can get G: to display in the Drives folder by running LVM and then exiting using Save and Exit - with no changes made and - Voila! drive G: appears in the Drives folder.
I would give David at least a few weeks time to investigate this and to react to your recently posted bug.
I agree with you that this needs fixing and if it's somehow reproducible, chances are not bad to fix it.
Indeed.