GPFault

Дальше будет много букв - поэтому общая суть и вопросы - сначала: Писал ли кто-то в последнее время письмо CandyMan с прямым вопросом о разрешении на открытие? Если нет, то на мой взгляд уместно (и я готов) написать ему по английски что-то в духе - "если вы откроете исходники, то у вас вероятно появятся новые... пользователи, как минимум я". Garl, есть ли принципиальные возражения против написания такого письма? Или это настолько глупо/странно/абсурдно, что и писать не стоит? Если CandyMan даст добро - будет ли согласие со стороны Garl? Теперь подробнее. Я возможно покажусь путаным/навязчивым/эгоистичным, но попробую донести точку зрения немного с другой стороны. Пользовался NDN 13 лет назад, и помню что он удобен. Сейчас я активно пользуюсь linux, в том числе во многих ситуациях терминалом/консолью. MC - не перевариваю, крайне малофункционален. Но NDN я уже давно не "щупал". Какая по факту причина? Без исходников присутствует абсолютно полная неуверенность в завтрашнем дне. Приучишься пользоваться, привыкнешь, потом что-нибудь поменяется в ОС что надо будет пересобрать с минорным изменением, а к этому времени авторы утратят интерес к проекту - и в результате ни исходников, ни улучшений от авторов. Открытость исходников - это по крайней мере гарантия того что получается избежать глупой ситуации "нужно минорное изменение, но его сделать некому, исходники утрачены или остались только у полностью незаинтересованных лиц". Такие заморочки наверное только у разработчиков) У тех кто сам "в случае чего" пересобрать не сможет в любом случае - таких заморочек нет. Исходя из написанного выше - что я могу сказать насчёт пользы от открытия исходников? Оценивая статистику я наверное что-то контрибьючу только в ~0.1-1% от проектов которыми я пользуюсь. Так что говоря честно - в случае открытия исходников - шанс что я что-то залью - статистически мал) Так что же произойдёт от открытия? Весьма вероятно что я попробую пользоваться ndn на linux, в тех задачах, которые у меня возникают. В случае успеха- может покажу паре знакомых. Понимаю, что всё звучит очень глупо, но получается что "открытие исходников принесёт проекту ndn некоторое количество пользователей, как минимум меня" )) Почему я например вообще не заинтересовался dn2l, даже как пользователь? Потому что по описанию мне показалось что для пользователя он гораздо менее доделан, чем ndn. Осознанно выбирать менее удобный инструмент когда есть более удобный ndn - ощущается странной идеей. Да и с проектом которым ещё нельзя пользоваться, я например связываться не готов. Большинство моих вкладов - это доработки уже вполне активно испльзуемых проектов. Более того, идея дописывать что-то в dn2l сильно демотивируется... перспективой что ndn откроют, и написанное для dn2l в этот момент станет или неактуальным (станет жалко потраченного времени) или придётся делать сложный и мучительный merge. В общем, совсем не факт что открытие принесёт хоть одного контрибьютера, это так. И если разработка делается только "для души под свои нужды" - то открытие вам ничего и не даст. А если она делается "для души для себя И для потенциальных пользователей" - то открытие исходников - это способ их привлечь) По крайней мере тех кто в подобных продуктах выбирает преимущественно открытые решения.

Hi. I'm back to this forum after 13 (!) years of inactivity. I'm not a DN user anymore (due to becoming a linux user, and ndn on linux wasn't stable 13 years ago), however, I still think that DN UI is tuned better then any other file manager, so I'm still inetersted in the "NDN on Linux" future. Recently I found information about somebody investing thier time into porting DN variant called DNOSP to linux - https://www.linux.org.ru/news/opensource/15971481 (text is in russian) The project link is https://www.linux.org.ru/news/opensource/15971481 The project developer said that he treated NDN as closed source-project. But technically, I think NDN has more mature linux support that the project I linked above, and it's a pity that human developer resources related to Dos Navigator was spent to less advanced variant (DNOSP) instead of more advanced NDN. As far as I know 13 years ago the source code was available to "anybody who really want to edit & contribute". I asked for it, ans Stefan provides me the archive (I've lost it many years ago). In modern days, such semi-private code development sometimes leads to waste of human resources (due to work on another variant as a I pointed above). Do nowdays ndn developers have any objections to publishing the entire source code? Are there any formal licencing issues? If the only thing that stops you from publising sources are technical - the lack of time or "dont want to investigate how to create git history" etc - I'd be glad to help in publishing it. For example: you choose the public hosting platform (gitlab, github, sourceforge or choose any other) send me the sources of several versions as archives and I create organization account on the hosting platform convert the archives to git history, publish sources on that hosting, and add your account on the platform as an administrator of that project. My actual e-mail is galkin.vv@remove.anti.spam.org@yandex.ru (English or Russian).

The problen I described in first post looks to be another problem - it applies only to F6 (renaming with alt+F6 works correctly) and it applies to directories and not files. Maybe I hadn`t described it clearly in first post. I have folder named BigFolder containing 1000 files. It is located in C:\FirstDir I want to move it to another place in drive C: - to the C:\SecondDir C:\FirstDir is in one panel, C:\SecondDir is in other one. I put cursor to the BigFolder and press F6, Enter. What happens: -NDN creates folder BigFolder in C:\SecondDir -NDN does 1000 renaming operations - it renames C:\FirstDir\BigFolder\file1 to C:\SecondDir\BigFolder\file1 and makes such operations for each of 1000 files. -NDN removes empty C:\FirstDir\BigFolder aybe even 1000 files. But for directory with complex subdirectory structure and a dozen thousands files in it the operations maybe really slow (a few minutes) Allmost all other filemanagers do this operaion instantly - they use only one OS filesystem call - renaming C:\FirstDir\BigFolder to C:\SecondDir\BigFolder and does not any recursion. So, the problem in whatsnew/todo looks to me as another one. If it`s really the same, I'm sorry. About recreation - I have this problem with both: -2.30.6778 in windows with custom settings on NTFS -old ndn v4000 in dos with default settings on FAT so it`s really strange if you hadn`t it

Hi. There is a problem in v2.30.6778/RUS (06-07-2007) WIN32, os - win2k3 (and as far I know in most previous versions in other operating systems): When I try to move folder within single drive (with F6) - NDN does recursive renaming. But it`s too slow if there is a lot of files in folder (>1000). Why single rename of the folder is not used? It`s a lot faster. If single renaming fails for some reason (locked files etc) - yes, in such case recurive renaming may be good idea, but not in general case, i think. Far, for exaple use single renaming and it works fine. In non-Windows OS's doing this with a single renaming is also possible. Thanks.

Hi! There is an error with deletion of directories with long names in NDN/W32. Unfortunately, I can`t say what is the first version where it appears, but it is some from last 0.75 year, maybe version where background deletion were introduced. Steps to reproduce bug: On LFN-only drive cretate a directory with long name like 12345678901234567890 Try to delete it - the following error occured ╔══════════ Erase ══════════╗ ║ ║ ║ Erasing the directory ║ ║ 123456789012 ║ ║ subdirs: 1 ║ ║ files: 0 ║ ║ Total: 1 ║ ║ ║ ║ Stop ▄ ║ ║ ▀▀▀▀▀▀▀▀▀▀ ║ ╚════════════ 0 ════════════╝ ╔═[■]════════════ Error ═════════════════╗ ║ ║ ║ Could not delete the directory ║ ║ D:\123456789012 ║ ║ ║ ║ OK ▄ ║ ║ ▀▀▀▀▀▀▀▀ ║ ╚════════════════════════════════════════╝ Looks like name is truncated to 8.3 Note: this error occures only on NTFS drives with disabled short names, not in regular drives Files with long names are deleted properly. Subdirectories with long names are deleted properly too, for example: I have folder d:\short\12345678901234567890 I go to d:\short\ , try to delete 12345678901234567890 - get error lioke above I go to d:\ , try to delete short - it is deleted correctly NDN: Version v2.30.3829/ENG (25-12-2006) WIN32 (W9x/WinNT) with all settings default OS: Win2003 SP1

It`s feature: here: http://forums.muxe.com/index.php?showtopic=766 ... [+] concurrent/background Copy/Delete is possible ... ([+] ôîíîâîå Êîïèðîâà íèå/Óäà ëåíèå)

You have chosen correct forum, so, it seems nobody knows how to change drive letters in linux version of ndn

Hi, alouette I haven`t any problems with FF1.5.0.7 (win32) So, it seem`s to be bug in your FF settings (though i`m not sure). Maybe it`s AdBlock( http://forums.muxe.com/index.php?showtopic...st=0&p=1892 ) Try to disable it. Please let us know if this helps. 2WebMaster(Stefan or somebody else(?)): if alouette confirm download link to be cut out by adblock it may be a good idea to change link. This seems to be common problem.

Looks like http cache is misconfigured somewhere (in ndn.muxe.com, your provider or some proxy, or in your browser) Archive size for last windows version (2.30.0024) is 1 084 839 You may try to download it here: http://gpfault.smtp.ru/_w32.rar (link is NOT permanent, I delete it next week)

Hi, coucou maybe this topic helps you http://forums.muxe.com/index.php?s=&sh...post&p=1892

Bug is not new, but only now I found when it appears NDN v2.30.0000/W32, all settings are default To reproduce: - Open/create in editor file with >=2 lines - go to first line - press End - press right (->) - press backspace Happened: second line is concatenated with the first Behaviour of many other text editors: cursor moved one character left Really, I don`t know which behaviour is better, and I`m not sure is it bug or wanted behaviour. What is it?

Hi, FoxCrunch The screen looks like you are running NDN in utf8 terminal, but maybe problem is more comlicated, because it looks even more buggy than i see in UTF8 linux console... Unfortunately NDN does not support locales and multibyte encodings, like utf8... So, the only thing that can help, is changing terminal options. You may try to put your terminal in some single-byte encoding, (like koi8r), or try to use another terminal like putty

OK. Sorry, if my previous post was too critical, I need to think on much of it again. int 80 is absolutely non-stndartized and really changes over years, while LINUX C API is fixed and never change. [very imho] the only non-ugly way to communicate with Linux kernel is using statically or dynamically linked libc. using int 80 intead of libc is like using ntdll.dll instead of kernel32.dll I see no way to change this situation mostly because of vp. [/very imho] Sorry, i didn`t look in sockets before your post. If there is really dynamic linking that works - it`s good but ldd says $ldd ndn not a dynamic executable (???) and pe2elf is really strange tool... such background processing in DOS is very good, but in modern multithreading OS background processing without inkernel threads is slow and imho ugly. when i say "UTF-8 support" i mean all strings inside NDN to be in UTF-8 (which is variable bytes-in-character encoding). Variable bytes-in-character lead to breaking most of TVision. So, speaking really, it is impossible. Converting to/from UTF-8 in interface with terminal and/or filesystem imho is ugly and lead to lot of bugs. here is the meaning of part i agree (not strict translation, but meaning is mostly the same): IMHO ndn developers should pay attention mostly to linux not to Windows. There are many file managers for Windows that are good. NDN is as good as Far, but it is nearly impossible to create a filemanager much better than Far. But on Linux platform there is no good console filemanagers and NDN have a chance to became the Main console fm for linux.

I 100% agree VP support for DOS/windows/OS2(?) is well enough, but Linux, hm.... IMHO vp linux support is extremly ugly and incomplete... Yes, the current linux version is not bad, but I think, that fully usable linux version can`t be created with vp. The main reason is: vp seem not support dynamic linking for linux, and many standard libs functions are reimplemented at kernel level (with int 80) So if full linux support is not one of the main lines of development vp is ok, but in other case vp isn`t. (all text after here is only IMHO) Also I 100% agree with this post There is many file managers for Windows. Generally, I think, Far is not much better than NDN, NDN is not much better than Far. For me NDN is a little better than Far, so I use NDN. If there wasn`t be NDN i had to use far in such case, it wouldn`t be a big problem. On Linux i have no good altenatives(mc isn`t), so i need use NDN, but now it has too much small bugs. Most of them are reasoned by the fact that firstly DN was old dos program and now it emulate DOS api on all OSs (not everywhere, but in many parts of code). Some things like attributes can be fixed, but some modern(ok, they were modern in 1992(?) when dn was born) technologies such as multithreading(background copy, calculation background completions of filenames in background), UTF-8 need rewriting of >>50% code. So the questions are: 2Stefan: Is good linux support among of the 2-3 main lines of development? 2All: Is here anybody except me who wants Linux version more than Windows one? P.S. I am NOT a big linux fan (now :) )

Ãòî íå îøèáêà NDN. Ãòî îøèáêà windows. Ìîæíî òðà êòîâà òü å¸ êà ê îøèáêó â âåêòîðíûõ øðèôòà õ, èëè êà ê îøèáêó â êîíâåðòà öèè CP866<->unicode. Åñëè èñïîëüçóåòñÿ Lucida Console, òî ñà ìûé ïðîñòîé ñïîñîá èñïðà âëåíèÿ - ïîñòà âèòü ïîïà ò÷åííóþ âåðñèþ îòñþäà Lucida Console Patched. Êðîìå òîãî, äëÿ íåêîòîðûõ âåðñèé windows ìîãóò âîçíèêà òü à ðòåôà êòû ìåæäó ñèìâîëà ìè äëÿ âåêòîðíûõ øðèôòîâ îïðåäåë¸ííûõ ðà çìåðîâ, ýòî òîæå ãëþê âèíäû. It isn`t NDN bug.