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 - lewhoo

Pages: [1] 2 3 ... 5
"I don't see anything else what's missing in a current Linux distro."

There are plenty of things missing or just made in a different way. As an everyday linux user (I have to use it at work, for scientific tasks), I find its archaic in many ways architecture very annoying. Complete rubbish in the file system, slow gui response (Xwindow), ideas that make using linux via ssh very convinient, but slowing down the system boot/response time etc... However, yes, I agree that this may be the only way to save something from OS/2. But for me OS/2 is not only the WPS, so it would be saving only a small part.

Hardware / Re: USB3
« on: 2012.03.01, 18:06:19 »
I used USB mainly with pendrive and the sad thing for me is, that the trasnfer is so slow on OS/2 mainly due to... bad FAT32 support. I know that USB is not only about memory devices, but until we get good FAT32 or NTFS support, improving drivers will not change much in that case...

Networking / Re: Almost dead network after qbittorrent
« on: 2012.01.08, 21:08:16 »
I've found the info about timout earlier and it helped a lot I think. I hope I do not say it to early ;) Now there is only one app that has apparent problems and that's an old, ported IM communicator. It disconnects or receives mesages much later, or loses packets...

Anyway, it seems that also the number of sockets is flooded: netstat -s gives maaaany entries after Qbittorrent is running.

The only solution about window list that worked for a moment here was deleting OS2.INI: PM_Workplace:WindowListPos -> SavePos, savin inig to other file, rebooting into command line, copying the other file over os2.ini and rebooting into PM. However, after reboot again, window list is in the hidden position. Apparenlty eCS somehow overwrites the position with the hidden value in the ini...

About icons, so far I tried only moving them, but it did not help.

I tried closing from sysmenu and moving to other desktop,if by this you mean menu->window->close of window list. Did not help. I also disabled ePager in "Screen", also did not help - did you mean this by "removing ePager"?

This was a fresh install of ecs 2.0, and the problem was from the very beginning. ertical bar is due to icon ouf of the screen, but when I move it, the icons are back within. However, ecs does not remember it and moves those icons upwards between reboots...

And still, that does not explain the windowlist problem...

I've got two problems since installing ecs 2.0, one more and one less iritating.

1. The more irritating: My window lists is always hidden below left lower corner of the desktop. I can only see its upper right corner, grab it and enlarge enough to drag it out of hiding. The system remembers its size, but not the position and after a reboot I have to do the same. I imagine that this might be connected to ePager, but I have no virtual desktop where the window lists is supposed to be displayed... Can anyone help?

2. The second problem is that my desktop icons tend to crawl slowly up from reboot to reboot. I always have a slider on the right side of my desktop after reboot... Here again, I would be grateful for help :)

Networking / Re: Almost dead network after qbittorrent
« on: 2011.12.17, 21:10:23 »
Unfortunately the problem reappeared. I wonder - maybe it is connected with me chaning priorities of different files within the torrent, however it shouldn't.  None of the options seems obviously connected to this behaviour.

The only thing I can think of is to uninstall QT and reinstall it....

Networking / Re: Almost dead network after qbittorrent
« on: 2011.12.15, 18:09:26 »
Thanks all. So far it seems to work, although I need longer time for testing. I deleted the qt config files in %HOME/local/share (or something like that). However, not all settings were deleted - it still knew where to download files (and there are people who claim that allowing apps to put their files where they want to does not lead to mess with which users have to deal...).

About the bandwidth - I definitely reduced the upload before, don't remember how about upload number. Well, I'll wait and see if with default settings the hogging will happen again.

Networking / Re: Almost dead network after qbittorrent
« on: 2011.12.13, 23:37:32 »
As I was afraid, latest qbit torrent with latest qt - similar problems. It is not necessary for qbittorrent to go to "stalled" to break other apps internet connection...

Networking / Re: Almost dead network after qbittorrent
« on: 2011.12.13, 22:46:25 »
true, it's not the latest: 2.6.7

Networking / Almost dead network after qbittorrent
« on: 2011.12.13, 22:33:59 »
I have a peculiar behaviour of my ECS 2.0 when using qbittorent (QT app). It happens only for some torrent,s not for all. Qbittorrent tnds to stop its download with "stalled' result and then the whole ecs internet connection starts to break down. IM clients often lose messages, disconnect, cannot connect etc. Firtefox can load only begining of pages or cannot load at all and cannot be properly closed - have to be killed. All other internet apps have similar problems. Only reboot helps, although I think that in the past a very long wait sometimes helped.

The only clue that I have is that opened OpenSSH session during this network breakdown ended with message:
Write failed: No buffer space available

Anyone can helpme solving this issue?

Setup & Installation / Re: RPM packager
« on: 2011.09.07, 15:19:21 »
Just to give a notice, I am familiar with RPM and yum, I have to use it nearly every day in it's native enviroment, so moslty the new thing I'll have to learn will be the GUI installer.

 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).

Simply not true. I just could say that, because I know much better how I fill using yum/rpm on linux and what I want. But I'll give some arguments:

1. small disks on notebooks, not easly changable
2. Multi-system installs
3. And finally - I always hated argument "just buy a new hardware". This is Microsoft argument. This is the way that most linux and windows software became badly written and unoptimized. I don't like buying new hardware because I am forced to. For me, many times, changing to a new hdd ment changing the whole machine.

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.

For me this is not the solution. This is a fundamental change in the OS and, I am completely sure of that, a downgrade. Linux was made to be managed by an admin, who posseses magical knowledge, not simple or even experienced (power) users. Now they attempt to make some workarounds around this fact. Here you try to implement such a workaround on a system,which has completely different idea behind it's design - here I am an admin, but an admin who does not have to possess all the magical knowledge and spend 10 hours a day learning it's system, to get things organized as I like in my system. I am a power-user. For me, one of your main tasks should be allowing power-user to remain the main user of OS/2. Older software allows that. I know this can be difficult with unix-ported software, because no idea of power-user exists on linux/unix. But that's a big part of core of what OS/2 is and why it is unique. And pleasedo not say - you will have a zip package. Resolving dependences manually and so on is most of the time task managable by an admin,not a power-user.

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.

So please make a browser of RPM "knowledge" with some kind of app like FC/2. With which I could move files around, see where file belongs, get apps automatically updated with information where their files now are. Well, I know that this would be a work comparable to writing the RPM from a scratch, so this is just to give you a hint. So for the beginning, just simplify getting files informations from RPM with a gui installer - I mean, don't leave us with a pure command-line (or GUI) listing,which we have to parse with our eyes or grep/awk/less, as is a common situation on linux.

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

How about backing up user data?

I think I could appreciate OS/2 version of RPM/YUM (not a port, a version), that would have reasonable gui, allowed to install every file where I want it to, and allowed me to browse every info I want in a human-readable way. This is my personal opinion as an end-user.

Setup & Installation / Re: RPM packager
« on: 2011.09.01, 22:44:11 »

There is a problem accessing previous posts in this thread, but I remember you asking me, why would I want to decide where to install a program. There are a couple of reasons.

1) Order. Order as I see it - usually you do not invite anyone to decide where to put things in your room. And even if you do at the stage of building your house, you choose from many projects. I browse through the file structure often,on OS/2, linux, windows. I know that there are plenty of windows user who never use any folder from hdd, but they use to pay other people for any simple maintanance. OS/2 users are not like that and they won't be - face it.

2) Ability to change order. I like to have my apps in different directories depending on their purpose. Dev, internet, graphics, etc. This is my personal idea. You may ask why would I want to access an apps dir? First of all for changing configuration files, cleaning rubbish (oh yes, current apps,includingthoseon linux, still produce lot's of rubbish) etc. You may say that on linux configuration files are in . dirs in home, not in root FHS. Yes,they are and... all the directories are there, no categorization, no use of an idea of structure of directories createdby user invented so many years ago. It's so archaic and so messy! Finding anything in this mess is a pain and working with all this is a pain. My home directory on linux is a mess and I did nearly nothing to make it so ;) My whole directory structure is a mess, I did nothing to make it so, but you just say it should not interest me. Well, it does.

3) Safety. Backing up with organized (and I don't call linux FHS organized) directory structure is much easier. Keeping different files on different partitions is much safer. It is still not so uncommon to have an FS error. In this way I can attempt to minimize loses. Currently - I am afraid that with FHS introduction no more.

To summarize - I do browse program directories. It's not my hobby, it is still a thing that you have to do if you want to do anything more advanced than watching movies. When I do it on OS/2, I enjoy it. When I have to do it on linux, I curse.

And to answer your recent posts. You write:

"From our perspective (trying to give OS/2 the future), this is a must do."

Well, it is nice to have any new programs on OS/2 (QT makes it possible , however, I'd be happy if we had a native-controls library available to write OS/2 native software,library such as wxWidgets). It's nice to have other solutionsfrom other OSs that make eComStation living. But you are coming close to crossing a line. A line where eComStation will have mostly some linux features and not many unique features. Linux ported software on linux-like FHS with linux like approach (dumb-user or admin)? What is there left to stay with eComStation then? WPS is not everything. If you will not use some of your developers time to preserve OS/2 uniqueness, you may very well kill OS/2. I know that that is not what are you willing to do and I hope that you will not do that.

"I can only repeat again that RPM has noting to do with FHS. Without FHS we will have to a) invent our own FHS and b) maintain a huge amount of OS/2-specific patches in every program ported from Linux which will be the constant source of bugs. Neither of these things will make programs better serve the user's needs. They will only be sucking our resources resulting in less software and bigger release delays. This makes no sense. Please stop aching and better learn to think different."

Well,you know what is a way to have no release delays, no bugs from additional patches, no additional sucking of resources? I have a perfect answer: use linux! It seems, that you have to learn to think different. I know that there is not enough developers manpower, but you have to keep in mind that porting to a DIFFERENT OS takes time! Again - either you preserve OS/2 uniqueness keeping in mind that porting will be more painful, or you are coming close to a line where you will kill a reason for using eComStation.

Most if not all of OS/2 community are power-users. We know what our system is about and we have well justified habits and needs. You can make a simple poll stating, what changes you'd like to make to eComstation and what of those users are willing to accept. Then, of course, looking at the results you may complain about dumb users. But these dumb users won't take everything that you will serve them.

Setup & Installation / Re: RPM packager
« on: 2011.08.30, 09:09:57 »

I think I can make a few statements about what I would like OS/2 version of yum and rpm to be:

1) Simply decide where I want to install my software
2) Know where the software is installed (in case of some default locations)
3) All options and possibilities accessible by GUI installer,no more complicated than WarpIn
4) GUI installer always compatible with rpm/yum
5) Advanced mode (in gui, not with 1024 bytes of command line) : choosing dependecies, where they are going to be installed, where the rpm should look for them, if rpm should extend path/libpath in config.sys,etc.

ad. 4. My experience with linux GUI frontends to software (in this case not yum guis, but other) is that often they are developed separately and finally when you want the newest vbersion of software you have to mess with command line anyway. A think that we have managed to avoid with OS/2 for years, at least in most cases

ad. 5. If I want my installed package to use only one version of dll that is not available to the other,etc. I'd like to tell rpm to install it in a different location and so on.

And to explain my linux experience:

1) Directory structure on linux, or at least on Fedora which I am used to, is a complete mess. Software can be installed in plenty of places,according to what the developer of package likes. When you finally have to compile software or untar.gz it and place it somewhere manually, you often have to look for an older version, edit script in path calling the real executable, etc. - quite often with new releases of firefox/thunderbird not given in an rpm or any nonstandard builds.

2) The dependencies are often a mess - you have a software that wants older vesion of lib s to work and won't work on newer. Either you have to stick with older versions of libs (and cannot use newer software), or resign from using it, or come through a pain of manually configuring and installing the package. It always seemed much easier for me on OS/2, maybe not only because of a much superior and clear OS/2 directory structure, but because somehow most of OS/2 libs are backward compatible and OS/2 programming was,at least up to date,much more responsible than linux programming.

3) As I said before - command line-gui connection is often broken on linux. Even more, linux command line arguments are often a mess, switches are cryptic, etc. This forces the situation: you can be a dumb user waiting only for new packachges available via yum and praying that everything will work out of a box (and all of us know, that it is not always the case) or you suddenly have to become an admin with knowledge much bigger than I would like to possess. Please, please, please, don't make eComStation like that!

Pages: [1] 2 3 ... 5