• Welcome to OS2World OLD-STATIC-BACKUP Forum.
 

News:

This is an old OS2World backup forum for reference only. IT IS READ ONLY!!!

If you need help with OS/2 - eComStation visit http://www.os2world.com/forum

Main Menu
Menu

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.

Show posts Menu

Messages - dmik

#1
Setup & Installation / Re: RPM packager
2011.09.12, 13:57:53
Andi, thank you for the detailed feedback. You are welcome -)

The problem with PYTHONHOME you mentioned is already fixed in the new version of the os2-base package (this statement is removed from config.sys if present), so one should not face this issue any more.

Maintaining the local RPM repository is fairly easy:

1. Install the createrepo package.
2. Add a file local.repo to /etc/yum/repos.d/ that contains:
     [local]
     name=My local repo
     baseurl=file://<path_to_repo>
     enabled=1
3. Put your .rpm files to <path_to_repo>.
4. Execute
     sh createrepo <path_to_repo>

I'm not sure if RPM tools will understand <path_to_repo> if it contains the drive specification, you will probably have to add a kLIBC pathrewriter entry that maps e.g. /drives/p to your P: drive and then baseurl will become "file:///drives/p/temp/build/RPMS" and for createrepo you will give "/drives/p/temp/build/RPMS".

P.S. I may sound tough sometimes, but I try to only operate on facts so there is nothing personal in my words (unless I explicitly state that), sorry if somebody got it wrong.
#2
Setup & Installation / Re: RPM packager
2011.09.08, 04:50:49
lewhoo, about hard disks. Given that in order to install all software avaliable for OS/2 you will barely need a partition more than 10G (remember, we don't calculate your data, it's separate), even five years old notebooks have space for 10 eCS installations. So this argument has nothing behind it. As for multiple eCS installs, RPM does everything for you, so it makes no problems to simply have everything installed everywhere and only share data. Regarding your 3rd point, you don't understand one simple thing -- the cost of maintaining software so that you can toss it around in any possible way and it still works is zillion times higher then hard disk space costs. Wake up! Nobody will do it. It makes no sense in 2011.

I don't undertsand why moving to the WPS level is not a solution for you. You don't present arguments. "It's a downgrade" and "other software works" are not arguments. "I don't feel okay with that" is not an argument either -- it could be if we were trying to sell a million egg slicers to houesewives. But this is just not the case.

The backup of user data is to be done the usual way. Copy/zip/whatever your %HOME% folder to a safe location.

lwriemen, there is no nothing or all approach. ZIP is not nothing. Yes, you may use logical volumes to seamlessly increase the hard disk size, this is entirely up to you (end-user). The concept of RPM is not fully clear to you -- its full potential opens up when it manages everything. But don't worry that much, it will not happen too soon. Re FHS, see the previous post.


Fahrvenugen, There is a difference from apps using OS/2 DLLs -- OS/2 DLLs are present on the system. Qt4 DLLs are not. Also take into account what Andreas said, he made a good point about OS2.INI which I didn't mention.

I understood your network share usage pattern correctly. I know all the stuff you mentioned, I did things like WSoD myself (I worked in a school as a sysadmin in the past; pupils are very aggressive users so I learned lots of stuff from there). While you may actually make this solution work in FHS pretty well (by redirecting /usr and /etc to a network share), this doesn't give you many benefits compared to the native RPM way where you may easily get the same "automated distribution" effect by installing/updating the necessary software from the user's logon script with a few simple yum commands. However, RPM, in turn, will give you a lot of benefit here because running the software from the hard disk is simply much faster than from a network share.

Pete, what you said about changing paths in OS2.INI when applications are dragged to different folders, is a fairy tale.
#3
Setup & Installation / Re: RPM packager
2011.09.07, 14:50:25
Quote from: ivan on 2011.09.07, 13:17:12
Quote2. No way to select the installation directory (imagine if the drive with UNIXROOT has no free space).

This is only relevant in a single user concept.  Business use has a different usage pattern that is usually a boot partition that is kept as small as possible and is transferred from an image file to the target machine.

The whole concept of the managing software installer is rather irrelevant in this usage pattern since the master image is static and carefully hand crafted anyway. But you still benefit a lot from RPM here because it allows to do *controlled* installs and structured updates of any software. This may simplify things when creating the master image and it also lets you deploy some applications right on the target workstations w/o the need to recompose/retest/redeploy the master image, which is obviously much faster and requires much less effort.

Quote
Quote3. No way to select the installation directory (I want things to be sorted *my* way). -- Each end-user application provided by us will have a WPS object. You can move these WPS objects on the Desktop to sort things the way you like.

Not good enough!  We have images of the tools directory and its structure as well as the utilities directory which can be placed on target machines as necessary - your idea is still single user.

The quoted answer is for the single user indeed, and not for your case at all. For you the answer is above. RPM lets you manage the images of such tools directories much more effectively than any other instrument you currently have. Much more effectively means less money on support.

Quote
Quote5. I hate application files spread across different directories.

You might have a small argument to do this on a single system - it does not work in any business situation I know of.

What do you mean when you say "a small argument"? I already presented many big arguments for doing so. Please read my posts. And what do you mean when you say that it doesn't work in business? It is not clear from your vague answer.

Quote
Quote7. I want to use the application on a machine where I have no Internet connection. -- Take its .rpm file. It is really easy to install the application from it w/o the Internet connection.

You will find in business what you are suggesting does not work - the admins have control of what may, or may not, be installed and the company firewall tends to stop the acquisition of things from the internet.

You seem to not understand what you are citing. I said that you *don't* need the Internet connection to have the ability to use RPM managed software if you want so. Regarding "what may, or may not, be installed", RPM gives you precise control over this. You probably don't remember but I already wrote that you can easily create your own RPM repository located in your intranet behind your firewall and stuff it only with the software you trust and need.

Quote
Quote8. I want to backup my applications. -- All applications we provide are backed up on our servers. No need to backup them locally.

Again single user thinking, it won't wash in a business.

This sounds like naked words to me. Please clarify what you mean.

Quote
Have you actually asked sys admins of businesses how they administer their IT?  Because as I read it you are focused on single user usage only.

I already said that we are focused on *general* usage. This includes the generic patterns of both personal use and business use. Most complaints here are from "single" users, hence are our answers. For you we have different ones.
#4
Setup & Installation / Re: RPM packager
2011.09.07, 14:00:39
Quote from: Fahrvenugen on 2011.09.07, 07:44:55
So yes, I do know what I'm talking about - moving applications from one folder and / or drive letter to another, using drag and drop.  And yes, it does work for many OS/2 based applications.

I didn't say that this does not work. You probably don't remember, but I said that this will only work for simple apps with no dependencies. This is not the case for modern apps we provide. Even a trivial kdiff3 utility needs the Qt4 runtime. Packing the Qt4 runtime with each application will increase its installed size by 40-50 MB even if the application itself is 500 K. This is insane and this will create an incredible mess of DLLs on your system.

Quote
I've used this technique to test apps before using them in production.

You don't need this technique with RPM. You can safely install/uninstall as many times as you want. Uninstalling the application will bring your system to the exact state it had before installing (except that the configuration file in /home/user, if any, will not be deleted, but this can't harm).

Quote
I've also used this to deploy apps that run from a network share - set them up on my local machine, copy the app over to a network share, then add an object for the app to all the desktops available on the network (and doing this involves a single command).

You don't need network shares to deploy apps this way with RPM. And this gives you significant benefits.

Thank you for your appreciation.
#5
Setup & Installation / Re: RPM packager
2011.09.07, 05:32:32
melf, your basic understanding of our idea is correct.

But I don't know what makes you think that we don't understand your concerns. The fact that we don't want to go the old way doesn't mean that we don't understand it (personally, I've been using OS/2 since 1993 and I had exactly the same concerns regarding RPM and FHS as you some time ago, even after getting some good Linux experience). What I want to say is that we are not able to provide quality software for the old OS/2 environment without changing it in some ways -- can it be more clear? Almost all system components in OS/2 are outdated, bogus and have limited functionality. This includes the base and the GUI libraries, the command line tools, CMD.EXE, the file system layout, config.sys and lots of other things. At some point this made the task of writing/porting the new software to OS/2 unmanageable. So, for us, the changes we are proposing are inevitable. You got it wrong. We didn't ask you about what file structure we should use on the boot drive and which installer framework we should port. What we are asking you about is this:

1. What are your most important concerns regarding RPM? We will listen and provide a solution, when possible, if it does not already exist.
2. How can we make this transition easier for you? We wish it to be as easy as possible for the end users.
3. What do you want to know about the upcoming changes? We are ready to help you and we want to give you understanding of things.

These are the current concerns we see, and our answers to them:

1. No GUI. -- Point taken, this is being worked on. Please, |yum install| until then.

2. No way to select the installation directory (imagine if the drive with UNIXROOT has no free space).  -- Please believe us, you will not want to do that after getting used to RPM. Given the size and the price of modern hard disks, it is not a problem to just get a bigger one to fit all you need. We may also come with a solution to at least select the target drive later (when the GUI is done).

3. No way to select the installation directory (I want things to be sorted *my* way).  -- Each end-user application provided by us will have a WPS object. You can move these WPS objects on the Desktop to sort things the way you like. See also 5. and 6.

4. I hate FHS. -- If you look at that carefully, it's just *two* new directories (/bin, /usr) in the root. /etc, /tmp, /var and /home don't count because they already exist in eCS (/etc and /tmp even exist in the original OS/2 under slightly different names). Two new directories is not that much, is it?

5. I hate application files spread across different directories. -- We know this is unusual for you. We agree that keeping all files in a single directory simplifies housekeeping, but this is not always possible on OS/2 due to some native limitations that we can't fix. And given that RPM always knows what files comprise the application no matter where they are, it does not actually make housekeeping (installing/uninstalling) more difficult in its case. If you are concerned about moving applications around for sorting purposes, see answers 2. and 3.

6. I not only want sorting, I also want to be able to quickly move the application to another machine. -- Let RPM do it. Given its knowledge about application files, it will be faster than you (and no removable medium is necessary).

7. I want to use the application on a machine where I have no Internet connection. -- Take its .rpm file. It is really easy to install the application from it w/o the Internet connection.

8. I want to backup my applications. -- All applications we provide are backed up on our servers. No need to backup them locally.

9. I don't want automatic software updates. -- RPM doesn't do that. It only behaves if you ask it to.

10. I want full manual control. -- We also provide ZIPs for all applications.

11. No transparency of things. -- Everything is transparent, it is a matter of learning a couple of RPM commands. Will not be necessary when the RPM GUI comes up.

12. You are ****. -- We love you too!

As you see, all your current concerns have or will have solutions. Yes, it requires you to slightly change your habits and to learn something new. But we sincerely believe this is for your own best and we will try to minimize the learning curve. Eventually, this will make your OS/2 life easier. And it will surely prolong the life of OS/2 itself.

CDRWSel, you are ignored.
#6
Setup & Installation / Re: RPM packager
2011.09.06, 23:27:30
CDRWSel, sorry but it is really hard to understand you because your English is very bad and it makes your words often contain no sense. WPS objects are completely unrelated to FHS, you will still be able to drag'n'drop them, even if the application is installed with RPM. More over, this is what we suggest you to do instead of taking care about real directories on your hard disk.

I am absolutely serious when I write something here. It looks like you also have problems with reading English, not only with writing. Either you do something with it (ask somebody to translate what I write and what you want to write), or I will not be able to continue the discussion with you. Sorry again.

I would like to add a word about dictating though (as this part of your speech I understood). Stop saying lies please. We do not dictate, we provide alternatives. For those people who needs the software we port and supports our work we will be providing two formats: ZIP and RPM. This will give people a plenty of choices: plain old ZIP for managing their own carefully cooked layouts or for creating portable applications, and RPM for those who wants all the dirty work done for them. If your only concern with RPM is the lack of GUI, you should better support us so that the GUI appears faster (there will be a prototype very soon to let you know how it will look and feel).

If you just want ZIP with the GUI interface (this is what WarpIn, given its limitations, effectively is) this is not what we can currently offer you, because it will only cause failed installations and nothing more. We know that, we have a lot of experience with Qt4 and other programs we distributed as WPI. Sorry about that.
#7
Setup & Installation / Re: RPM packager
2011.09.06, 20:51:59
Quote from: Fahrvenugen on 2011.09.06, 19:14:29
I disagree -  I drag and drop entire OS/2 based apps all the time and rarely have a difficulty.  This is one of the features of OS/2 that sets it apart from  other operating systems - it easily allows you to do this - move around either data files or entire apps without breaking things (and it even updates your shadows and objects properly) - all due to the OO technology built into the system and WPS.

We do not speak about WPS here, we speak about moving applications from one folder to another on the hard disk.

ivan, the joke here must be your concern about the installer size. RPM itself is only several MB. The rest is Posix core utilities and libraries needed for many other software. Counting them together has as much sense as counting together WarpIn and all DLLs in \OS2\DLL.

"'I'm the developer and I know what you want" -- first, neither me, nor other devs said that, so please don't refer to it. Second, now we do know what you want indeed, after you have told us (if you were not lying, of course). Third, we do know what some other users want because they told us too. Fourth, we do know what we need to do on the system level in order to deliver software of a certain quality. We know this better than an average user not because we're just cool but because this is our job and we have experience. And, BTW, refusing to trust the developer in this area may leave you with no chances to ever have LibreOffice 3.3 and other things you listed. Just so that you thought of that too. Our work is partly sponsored by the community and we feel great responsibility before it for what we do. But to do our best we should be trusted.

Saying more on that would be off topic here, so if you want to continue this discussion, feel free to start another thread. Regarding the test process, this is part of the idea, keep throwing. But please don't repeat the same thing over and over again -) It just wastes your and our time. Thank you for understanding.
#8
Setup & Installation / Re: RPM packager
2011.09.06, 02:47:19
CDRWSel, I already told you that FHS suits the needs of optimizing SSD usage better than anything else. No need in revolution, just map /home, /var and /tmp out of SSD (actually, you can already do it in eCS with the path rewriter tool) and you will get what you describe as satisfaction. RPM is not involved here at all.
#9
Setup & Installation / Re: RPM packager
2011.09.05, 15:01:17
CDRWSel, yes, bootstrapping RPM takes about 60MB. But this includes Posix coreutils besides RPM itself plus some system DLLs needed by all programs. It's a bunch of useful command line tools which we have to provide because the OS lacks them.

Regarding DnD. I already mentioned that you can't DnD programs which need a specific environment that depends on their location (PATH/LIBPATH/WPS). Besides, it is not fully clear why you need keeping to DnD your programs around. Possible answers (I'm guessing since you are not specific):

1. To maintain your own order of things, as lewhoo already mentioned here. My question: why dragging & dropping the WPS objects of programs instead is not enough for you?
2. To be able to easily transfer the program from one PC to another. Our answer: with RPM you don't need to do such manual transfers. If you still want it for some reason (you are in the forest with no Internet connection), you can take the raw .rpm file and install it. The raw .rpm file is much like the .wpi file. The YUM/RPM GUI will include a simple interface to install it by double click w/o the command line.
3. To backup. Our answer: you don't need to backup software with RPM. You may easily recreate the exact installation of your software with a single command (mouse click, once GUI is ready).
4. To optimize hard disk usage. Our answer: this is not a user-level task. Hard disks are extremely cheap nowadays, just buy a bigger one and copy your OS/2 over to it. If you want to use the bloody expensive SSD gear, you want something unusual and you have to learn how you can optimize FHS and things for it. The cost of maintaining all software in the world easily relocatable on OS/2 is orders of magnitude higher than you could pay for that.
4. I ran out of ideas here. Feel free to add something.

The command line interface of yum is very well user-oriented.

Regarding your question about portable apps, no I don't use them since I don't need it. And I don't know people around me that would use them, frankly. There are very few cases where it would be necessary. In either case, creating an USB stick with the portable application on it has nothing to do with RPM. The level of work it requires depends on the software you want to make portable. RPM can add more work here, but since it is not something needed very often, we don't care too much about that.

What you say about the developer's approach is true (with a few obvious exceptions) but only when it comes to the UI (*user* interface). Everything else is none of the user's business. What you say about the stupid Windows Update system has nothing to do with RPM. Nothing.
#10
Setup & Installation / Re: RPM packager
2011.09.05, 03:30:22
Pete, thank you, we will add a line to README that all previous installations of python need to be removed.

I think you misunderstood me again. If you want to install Java, you type |yum search java| and it will show you the exact names of the packages whose descriptions or summaries contain the word "java". If you don't know the name of the program you want to install but still want to install it, well, this is unusual, as I said.

CDRWSel, what is your definition of "very big"?

It was never possible to move the program to a different location with drag & drop on OS/2 (except very trivial programs that don't have entries in config.sys and don't have WPS objects).

What you say about RPM/YUM further shows that you have neither knowledge nor even basic understanding of what RPM/YUM is (and you don't seem to know WarpIn well too). I'm not going to repeat everything once again, sorry. Please read the respective sources of information on the Internet and ask questions if you have them. Your words about portable applications show that you have weak understanding on how they work and also that you don't read what I write to other people. Please do.
#11
Setup & Installation / Re: RPM packager
2011.09.04, 18:20:10
Pete, having got the yum/rpm bootstrap working needs no more work than having got any other application distributed as ZIP or WPI working. So not quite clear why you explicitly mention that.

Your argument about the long output of yum is childish. Any command line application has the same problem, yum is nothing special here. But you normally don't need to list all available packages. When you want to install something, you already know its name (and you can easily limit the output to just that, see the table of commands in Wiki).

If you read the yum WPI README carefully, you will find steps necessary to uninstall it.

David McKenna, there will be a GUI soon. We significantly increased the priority of this task due to your feedback.

ivan, I said "if the other installation was *also* RPM-managed". RPM can't do anything with installations not managed by it. Regarding config.sys, see above my reply to Pete.

With RPM, you do not need to change the file structure. The RPM bootstrap (and further updates) will create the necessary structure on its own. Many programs you mentioned actually have their own UNIXROOT tree inside them which usually contains all other 3rd-party software (including system components) they need. This is bad because:

  1. It creates duplication of system components which may cause conflicts. There is no clear way to use different versions of the same DLL on OS/2, especially if they both should be loaded at the same time.
  2. Even if you manage to have two different DLL versions loaded at the same time by two different applications, some system DLLs (e.g. Qt4 or Java ones) are so big that it will have a negative impact on your system (because the shared memory area where DLLs are loaded is very limited in OS/2 and because they may use a lot of private memory for some tasks which will be duplicated) . Besides, this may also break interaction between these applications because of two copies of system data in memory.
  3. It makes it difficult for the programs to cooperate with each other (some parts of UNIXROOT are meant to be system-wide and shared across applications).
  4. Needless to say it requires putting each application to PATH/LIBPATH which requires reboots and eventually creates a mess in config.sys that you constantly need to keep an eye at (especially when you remove something from your system).

BTW, all of the above actually also applies to applications not using UNIXROOT but simply supplying everything with them and keeping it in its private directories. Yes, this is how applications are distributed on Mac but you should not compare Mac and OS/2 here. Apple has full control over the OS internals and they can optimize things to work this way; we can't. Also, a typical application on Mac doesn't have external dependencies because all frameworks Mac applications use are already supplied with the system. There is no way to achieve such a state of affairs on OS/2 (for obvious reasons).

RPM can do exactly the same of course, but since it is what we consider a bad thing, we do not want to do that. We ported RPM to solve the above problems, not to keep creating them.

All programs you mention, distributed as they are, require careful manual setup which sometimes may be hard if you are not an expert. Even if you are, you can simply mistype a single slash or a semicolon and that will break the installation. I don't know why you find this exciting.

I didn't fully understand what you were saying about the server updates. If you mean that in your infrastructure workstations run their software from the network drives so that updating the server causes all workstations to be updated, then RPM lets you do exactly the same but but in a much better way (by at least removing all the problems related to the need to run the software from a network drive).

CDRWSel, about UNIXROOT and config.sys, please see above.

Regarding the hard disk space taken by RPM. If you mean the fact that the current RPM repositories cause RPM bootstrap to install GCC binaries and LIBC headers on your machine, this is a bug and it will be fixed.

I fully understand your concerns about SSD, but it is not clear to me why you find RPM guilty here. It will only perform actions when you ask it to do so. Otherwise, it does nothing.

Regarding SSD per se, I must say that UNIXROOT is a *big* helper in this area because of its strict structure. There are basically two directories in FHS which get written to during normal operation of the OS: /var and /tmp (and /home of course); programs are not allowed to write to other directories (and under Unix/Linux they simply can't). For SSD it's just perfect: you move these two directories to a device that is fine with frequent writes (e.g. to RAM-disk) and live happily.
#12
Setup & Installation / Re: RPM packager
2011.09.02, 21:55:20
Blonde Guy, yes, the UNIXROOT tree may live in any directory on any hard disk. It is recommended to install it to the root ATM (there may be a few exceptional applications still having something hard-coded like /bin/usr instead of /@unixroot/bin/usr that will fail if UNIXROOT is not at root -- this needs testing) but this is all fixable (we have plans to fix them all at once at LIBC level). Other than that, YUM has a Python interface which you may use to control it. RPM itself has a C interface.

Fahrvenugen, yes, sure, I love questions (and sometimes my explanations may be not clear enough indeed).

Regarding Windows, yes, I do really think that the Windows mess is a consequence of the lack of a tool like RPM. As a result, each vendor uses its own approach, installs files in a way he thinks is the best, leaves garbage all over (including system directories!), stores hundreds of MB of stuff you don't need (like the installer files) in well hidden places. All this means that if you ever installed an application, you won't be able to completely remove it later, even if you don't need it; the uninstallation procedure is never revertible on Windows. Subsequently, if you install software from time to time, your system directories will finally get so big that you will have to kill the whole installation. Everybody knows how painful it is to reinstall Windows: you need to find/download/reinstall every piece of software + a big bunch of drivers. This may take many days.

RPM (or DPKG) solves *all* of these problems. You know the origin of each file in the system, the application it belongs to, and the version of this application. If you uninstall the application, *all* its files are removed (except the application data in your user directory which includes application settings and documents you created), so you may install/uninstall as often as you like without any impact. The only thing you need to do after performing a fresh installation of the OS to get all your applications back, is |yum install <your_beloved_app1> <your_beloved_app_2> <etc...>|. A single command.

The statements you mention are not actually opposite. When I say "RPM forces the FS layout" I mean that most system packages will install files to the locations predefined by the software vendors. While RPM itself has a mechanism that allows creation of packages whose installation paths may be changed (prefixed) at the installation time, the whole model is not designed to be used that way: it is designed to not require any user interaction when installing software (which implies predefined paths). In this sense, FHS is just a logical complement to this model because it documents the standard on common system locations (so that vendors don't have to invent their own predefined paths for each new software package). Besides that, FHS happened to be used by many Unix environments (and, consequently, by many Unix programs), for similar purposes.

Pete, glad to hear that. Must be a conflicting version of some python library (wouldn't be the case if the other installation was also RPM-managed -)

aschn, thanks Andreas.
#13
Setup & Installation / Re: RPM packager
2011.09.02, 15:16:09
I must explicitly state that we are *not* trying to make Linux out of OS/2. We want to keep the native "weightlessness" of OS/2, the ability to work for months w/o maintenance, the possibility to unzip the boot drive onto a new hard disk and get it running, as well as the WPS concepts; all just powered up with new technologies and software.
#14
Setup & Installation / Re: RPM packager
2011.09.02, 14:51:23
lewhoo, if you want your own order and manual control in the system area, why do you need WarpIn? It looks like an obstacle in this process too (as it may and will dictate you some things). However, if you like order, there is still a way to get things look like you want, even with RPM and FHS. You have WPS, you may organize things there according to your preference. This is just another level of abstraction where we offer you to move. One idea behind RPM is that it sorts things out for you, so you don't need to care about them any longer -- they will work without you being looking at them in File Commander.

I assure you that porting the current software to OS/2 will remain painful enough regardless of whether we use FHS or not. This is due to bugs in the native components that will never be fixed and due to the lack of the documentation that will never be written. The original OS/2 directory structure and the way how people are used to manage software may be unique but this is not what we think is worth being preserved in order to keep the OS/2 spirit alive.

miturbide, your conclusions are naked. I think you know yourself why. Thanks for the feedback though.

djcaetano, some of your points make sense, but see below. I'm open to discuss things further, but only if we go to the technical level where the practical purpose dominates, not the old habits. Regarding FHS and the entire system, it will probably shock you but this indeed implies replacing the OS/2 core utilities with the Posix ones (e.g. sh.exe instead of cmd.exe). The OS/2 ones will stay too of course (for the compatibility reasons), but in a separate command prompt.

Regarding the high learning curve, the idea is (I repeat) that our model assumes that you don't have to know the command line at all (except for 'yum install', but this is a temporary exception). Regarding the boot problems, drivers is a completely separate area, I don't get why you mention it. Luckily, we still have a few developers working on them, so there is a chance to have it running in native on the current hardware.

To all three of you. The discussion shows that we have two distinctly different visions of the OS/2 future. You don't like and don't need things that we do. I see no problem with that. Just don't use what we offer. We can't and we don't want to force you. Don't install RPM, don't let us create the FHS mess on your system, don't use Qt and Qt applications, don't use messy Paul's ports. Do things as you want them and be happy -) The future will show whose position is more realistic.
#15
Setup & Installation / Re: RPM packager
2011.09.02, 00:27:33
miturbide, you say "FHS gives no real benefit to the users". Yes, this is true. We agree on that. Where is the problem?

Regarding "other OSes not using FHS", you are speculating. There is only one OS not using FHS, all other OSes (a dozen of actively used ones) do use it and work not just fine but often much better than that OS. Again, what is wrong with that?

melf, please do not speculate on words, either. This is a bad practice. I can't speak for Mensys, actually. When I say "eCS will be..." I express the plans of the group of developers. But it will not surprise me if Mensys also wants to have a better software management infrastructure.