Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Herwig Bauernfeind

Pages: [1] 2 3
Networking / Re: Samba Server
« on: March 16, 2018, 09:39:07 am »

some thoughts:
1.) Dave Yeos tip is the best. Makes sense and do that. Eventually delete any master.passwd, pwd.db and spwd.db before installing.
2.) Rich Walshs tip is ok, too. However Samba not requiring master.passwd et al maybe be technically correct, but not a good idea. It is however completely wrong that the GUI tools impose the usage of the *nix password database. It is the Samba core that requires the *nix password/user database for certain operations (not all).

The whole philosophy of Samba and it companions (and basically this is exactly the same with *nix) is to keep the *nix user/pssword database and the one from Samba synchronized.

In case the synchronization is lost (for example due to manual modifications), things start getting in any degree from strange, weird, to absolutely non functional. Your mileage may vary. Getting the 2 asynchronous databases back to sync again is (almost) impossible.

3.) SSCC (Simple Samba Configuration Center) does not come with a master.passwd because it creates it from scratch in case none is found.

4.) The error you see when logging into Samba Users and Groups is interesting. It is obviously unable to parse something very weird. I'd like to know what and will try to provide a fix for that. Your problem is however likely the one described in item 2.) last paragraph.

Programming / Re: Trying to build my First RPM Package
« on: February 09, 2018, 08:04:49 am »
There is a logs subdirectory under rpmbuild the complete logs are there.

Storage / Re: Extended Attributes - OS/2 only thing?
« on: February 04, 2018, 08:05:58 am »
Not forget one thing: Most NAS boxes run Samba as their network server. Samba has to be configured to support EAs. This is done by adding

    ea support = Yes

to smb.conf

Utilities / Re: Unzip 5.52 vs 6.00 date differences...why?
« on: October 21, 2017, 01:40:45 pm »
I discovered that installing the currently available unzip package gets me unzip 6.00, with a side-effect though!!!
By "currently available" you think of the current rpm/yum package?

We fixed a wildcard problem there several months ago. In case there are still issues with the current one, drop us a ticket, and we will look into it.

Best regards,
Herwig Bauernfeind
bww bitwise works GmbH

Programming / Re: Get a Free copy of ArcaOS 5.0.1
« on: September 26, 2017, 12:16:11 pm »
As bitwise works is the maintainer of the VBox port for OS/2, we would have appreciated if you had contacted us before posting your offer here. Unfortunately it will take quite some more financial effort than the cost of an ArcaOS license.

We encourage everyone to buy development units for the VBox project in our webshop

in order to ensure the port is enhanced.

Herwig Bauernfeind
CFO bww bitwise works

Programming / Re: poll() and select()
« on: June 25, 2017, 09:09:29 am »
I suggest to talk to Dmitriy Kuminov about the implementation in libcx.

We had to deal with the same problem on Samba.

Applications / Re: Firefox 45.5 Install issues
« on: June 15, 2017, 11:44:52 am »
In order not to waste Dmitries precious developer time, I will try to fill in the gaps

Dmitry, your explanation fills in some holes but does not explain why if our computers have been running for more that a week we can start, for example, Open office 4.12 but if after closing it we can not start vBox 5.06 and trying to restart OO throws a fault of not being able to open SC.DLL.  At that stage even EPM which we use as our standard text editor stops responding and we have to reboot.

The reason is quite simple, though not really obvious: Todays applications (such as OpenOffice or Vbox) are so demanding with respect of memory, address space that we are continuosly bouncing into the limits of our beloved OS/2. Just remember: Back then NO application required that much memory, address space and the like. While we are (theoretically) within the bounderies of OS/2, nobody at IBM back then tested, whether an application that huge still worked under alle circumstances - simply because there was NOT A SINGLE application that huge. The possibilities why something might fail are endless and one especially annoying issue is that the OS fails to free ALL resources these huge applications need when running. So: After a week (or earlier) some resource of the OS has been so badly eaten up, or fragmented, or.... that you have to reboot.

Software from back then never used up enough resources to even show the problem, because it simply would take too long.

It has worked for years without problems but now ....
Sure. Use the software you used back then it will still work endlessly. That is not an option? We know that is why we are here....

However, we do not have the source code to OS/2. Unfortunately.

Applications / Re: Firefox 45.5 Install issues
« on: June 01, 2017, 08:20:12 am »
One frustrating problem I have encountered that occurs on AMD boxes is the "age old" sagging desktop icons. This is not a problem on my Intel box.

It happens here on the Intel boxes as well and is unrelated to to CPU type.
This is a WPS bug which can be worked around by using from time to time.

The invoking of the script is a bit clumsy, but it works very well. Until it starts to happen again (which can be expected from the nature of the bug).

Applications / Re: Firefox 45.5 Install issues
« on: May 31, 2017, 08:50:47 am »
Ivan, currently I am not aware of any AMD based testing machine - I phased out my last SMP AMD based machine some 1,5 years ago...

However, this was only an issue when I built an AMD-optimized Samba back then (which was never officially released, but worked well, the last one was a 3.3.x one....).

Basically we build for generic i686 (PentiumPro) instruction set, so in theory it should work on everything better than a Pentium/AMD K6.

Addendum: I just learned that one tester uses an AMD based machine, so: Yes.

Applications / Re: Firefox 45.5 Install issues
« on: May 30, 2017, 09:35:44 am »
A few notes:

- We are testing on a mix of several language based OS/2 versions. Usually the language does not really make a difference (except SBCS vs DBCS or cyrillic issues which happen to creep in from time to time).

- A working IP connection to the internet (or any other network) is NO must have for RPM/YUM. An installed IP stack is a requirement. Python is a requirement, too.

- The DLL hell is a reality on ALL operating systems. It simply does not make sense to statically link every single requirement and thus reduce the number of required DLLs. The reason is that architectural constraints especially on our platform make that a bad idea being the source for more problems than you can imagine. We have been there. A statically linked FF does not work on OS/2 anymore. Niggling about the DLL hell and how bad it is, is as useful as niggling about the color of the sky. You don't like the DLL hell? Me neither. And I like to think about the times when "our" OS did not have it. Too bad these times are simply gone.

For those who have to operate a standalone machine that is not connected to the internet, it is possible to use RPM/YUM locally only. It is advisable to create a local RPM repo, disable the netlabs and ArcaNoae repos, copy any installation package to the local repo and let YUM install it from there.

I need to check how good and simple the docs for that scenario are, if they are not good enough, I will overhaul them.

Applications / Re: Firefox 45.5 Install issues
« on: May 29, 2017, 11:55:41 am »
You have no better to do than spreading fake news here.
Nonsense. A news with an example as source hardly qualifies as fake news...
The current situation under OS/2 is a total disaster for end users of your "ported" applications.
More Trump-speak. More nonsense. Simply a blatant lie.

There are 2 ways to successfully run applications on a modern OS/2 system:

1.) Go the RPM/YUM way. Stuff simply works in most cases.
2.) If there is an older version library that is required by an elder application under any circumstances - use LIBPATHSTRICT. PMDLL is your friend.

Regarding Andreas Kohl: I have been advised to ignore his niggle and utter nonsense. He constantly fails to substantiate his claims anyway.

Applications / Re: Firefox 45.5 Install issues
« on: May 28, 2017, 06:00:07 pm »
tuppenny-ha'penny people.
Well, neither bitwise nor Arca Noae are IBM, we are much smaller, simpler, you name it. But still better than a person that only is capable of ranting....

Is this really meant still seriously?
Yes. Being eager to learn, we are waiting for your presentation of ANY better alternative.

Applications / Re: Firefox 45.5 Install issues
« on: May 28, 2017, 05:51:06 pm »
Well, an (half-ported) package manager from the late 90ies and an update mechanism from early 2000 is the ultimate solution nowadays.

Ultimate solution? Your words. bitwise never said that. However, the solution that made most sense. And it can't have been that wrong...

Anyway: You are free to provide a better solution. Not just ranting, write the code, provide the packages, do the maintenance. "Hic Rhodos, hic salta!"

These are completely ridiculous explanations.

They appear ridiculous only if you missed the most important point. I bet you will not guess which one I meant. Just go through my writing once more and do a careful reading.

Hint: Conservative minds often miss that point.

Applications / Re: Firefox 45.5 Install issues
« on: May 28, 2017, 05:39:23 pm »
Why RPM/YUM, we have beautiful WarpIN

IBM endorsed RPM/YUM on other systems and there is reason to believe that if OS/2 development had continued, there would be some sort of RPM/YUM for OS/2 from IBM.

About WarpIN: I was a WarpIN fan myself (you possibly know some of my software that came as a WarpIN package) and there were quite some discussions in bitwise, about RPM/YUM being that ugly and WarpIN is so nice anyway.

I had to learn that WarpIN simply is not good enough - it lacks several features direly needed by a modern package manager. From the architecture point of view, extending WarpIN was considered, however the design of WarpIN prevents that.

What we do these days, is to enhance our RPM/YUM to embrace WarpIN.

In addition the number of OS/2 specific features of RPM/YUM is increased and enhanced. Missing features found in WarpIN missing in RPM/YUM are added (for example install a font in OS/2, RPM/YUM cannot do this at the moment - expect to see that change soon).

if we use the latest vBox we have to reboot to use OpenOffice 4

For sure not an RPM/YUM based installation, as that definitely works. This is exactly the reason, why it does not make sense anymore to install that stuff manually. I cannot answer your question, I simply do not know your machine. If you had done it using RPM/YUM it would work.

Sorry, I understand your feelings, but doing it manually is simply wrong.

Applications / Re: Firefox 45.5 Install issues
« on: May 28, 2017, 02:07:54 pm »
I have to address some statements in this discussion:

OS/2's human package manager

Why does OS/2 rely on a human package manager? Because its architecture is from the early 1990ies. No need for automatic package managers back then.

However: It is quite arrogant to assume that all other OS maintainers (no matter whether these are the Linux, Windows, FreeBSD, whoever guys) are rather dim and incompetent to create such beasts for other OSes when in reality they were not needed. 201x software (especially bigger programs) are simply too complex for a manual approach.

Firefox 45 is a 2016 piece of software: The problems to get all DLLs together are not OS/2 specific - all the other OSes got package managers to do that job. NOBODY on other OSes asks for specific DLL requirements to be manually downloaded "somewhere" and copied into specific locations - the question for that (unless for specific research purposes) would be considered plain stupid and obsolete.

The RPM/YUM port is an attempt driven by bitwise works and Arca Noae to close this gaping hole in the OS/2 architecture.


If you want to run software the 1990ies way on a 1990ies OS, please use software from the 1990ies - an automatic package manager would not really be required then.

If you want to run software from the 201x on a 1990ies OS, please do as the ones who DO THE WORK on that stuff suggest. We know what we are doing and why we are doing it the way we do it.

If you do not want to do it the suggested way - you are free to do so. You just need to do A LOT OF RTFM and use PMDLL as a tool to overcome the arising difficulties...

Maybe it is time for you to review your point of view. But please don't steal our time by asking 1990ies questions in 2017. They have been solved - use RPM/YUM - that IS the solution.

It's a disadvantage of lacking competition.

It looks like you are suffering from blatant illusions. I wish the OS/2 market and community was big enough to make competion a healthy option to get the best alternative solution for a problem. The reality is, that the main problem is, to get enough manpower to complete ONE solution for a single problem.

Discussions whether there would have been other (possibly better) solution is senseless - there is simply nobody who will create it.

Critisizing certain aspects of current software (OS and application) is absolutely valid and welcome - however make sure you got a viable alternative solution at hand, a simple rant just is not good enough.

Pages: [1] 2 3