Именно. Тот же РТКомм не будет вести оптику до каждого пользователя, там идёт работа в других масштабах. "Толстые" каналы арендуются различными провайдерами, которые, в свою очередь, могут сдавать их провам поменьше...
А в итоге, из-за этого, имеем накрутку на стоимости траффика =(
Я не только не хочу платить за чужой опенсорс, но и не хочу, чтобы платили за мой опенсорс. Это неудобно, к тому же налагает на разработчика обязательства (даже если выплаты сугубо добровольные).
Но я плачу за чужой проприетарный софт, и хочу, чтобы за мой софт тоже платили.
>Тот же тотал коммандер, будучи с окрытыми исходниками уже бы был на 64 бита да и все его плагины до кучи.
Нет, не нужно этого! У TC есть свой цикл развития, который соблюдается уже много лет. Хорошая программа приносит разработчику деньги, как стимул продолжать разработку. К тому же, когда контроль над разработкой и развитием ведётся одним человеком - оно как-то спокойнее. Группа со-разработчиков, предлагающих идеи и занимающаяся альфа-тестингом - хорошо. Но распыление кода - не очень хорошо для подобного проекта.
Можно провести эксперимент. Как известно, FAR с версии 1.80 ушёл в опенсорс. Мажорная версия TC была на этот момент 7.0. Давайте подождём до выхода TC 7.5 (по моим прикидкам это будет вторая половина 2009 года) и сравним количество и качество улучшений в том и другом менеджере.
>Ну вобщем да, есть такие - Борланд пролопушили и у них нет делфи для 64 бита
Обещают уже в этом году (см. роадмап).
>тотал коммандер насколько я знаю только 32х битный
Нет, он ещё и 16-битный был до последней версии (для Win 3.1). Отсутствие 64-битного компилятора - не единственная причина, там вообще используется компилятор от второй версии Delphi - он даёт более компактные и быстрые бинарники.
Ещё одна причина, по которой переход на 64 бита для TC затруднён - изменения в плагиновом API. Придётся переписывать сотни существующих плагинов, а многие авторы их уже давно не поддерживают.
Да и не будет для TC никакой выгоды от 64 бит. Разве что CRC будет быстрее считать, да плагины, которые большие объёмы данных обрабатывают, будут чуть быстрее работать (при условии, опять же, что и их портируют).
> А вот у опенсурса все гораздо лучше, фрипаскаль и соответственно лазарус умеют 64 бита не только нативно, но и кросскомпиляцией, так что это беда программиста, что он облажался при выборе языка.
Не могу сказать про это ничего. Ни разу не видел ни одного стоящего приложения, скомпиленного тем или другим.
Но вообще уходим мы от темы. Я своим первоначальным постом хотел сказать лишь, что винить программиста - глупо. Подождите, 64 битный софт года через три-четыре возьмёт своё. 32 бита тоже не сразу пришли - 386 процессор эвона когда появился, а 16-битный софт только со времени 95 винды стал исчезать (да и то, только к XP пропал почти совсем).
>Я ставил в параллель Убунту х64 и х32, разница была заметра даже по времени загрузки.
Я не могу сказать, за счёт чего идёт выигрыш во времени загрузки. Но вполне допускаю, что там может быть какая-то оптимизация. Но опять же - тут раз на раз не приходится. Могу предположить, что большинство обычных программ, используемых на оыбчном десктопе от 64-битности ничего не выиграют.
Кстати, как-то баловался с Suse 32 и 64 - разницы не видел никакой...
Об этом уже сказано и пересказано много раз. Если вкратце:
- Переписывать под 64 bit имеет смысл только приложения, которые реально могут это преимущество использовать. Т.е. софт, занимающийся какими-то расчётами. Для пользователя это могут быть программы кодирования мультимедиа, обработки 2D/3D графики... да и, пожалуй, всё. Тот же Skype вряд ли выиграет в производительности.
- Не всё зависит от программиста. x64 компиляторы есть далеко не для всех ЯП, и, даже если нужный компилятор найдётся, портирование перекомпиляции.
Таким образом, знания программиста, и тем более его финансовые возможности имеют довольно слабое отношение к нехватке x64 софта.
После третьей версии ACDSee (новые резко не понравились) перепробовал много-премного разных смотрелок. Но, в итоге остановился на плагинах к TC Imagine и SGViewer. Они превосходно дополняют друг друга, а в сочетании с самим TC делают абсолютно всё, что мне может потребоваться.
Троян? Вряд ли. Сейчас точно не скажу, но, если я правильно помню, historylib - библиотека синхронизации историй. Могу ошибаться.
Но точно уверен, что никакого трояна там нет (в оригинальной дистрибутивной библиотеке, имею в виду).
Голосовать не буду, скорее всего, - лень за открепительным ехать.
А в итоге, из-за этого, имеем накрутку на стоимости траффика =(
А что копирайтов нет - так Кагановские шедевры и без всяких копирайтов узнаются.
Но я плачу за чужой проприетарный софт, и хочу, чтобы за мой софт тоже платили.
Не может.
>А вот насчет тотал коммандера - так он, вроде, написан на Delphi 5
Delphi 2
Нет, не нужно этого! У TC есть свой цикл развития, который соблюдается уже много лет. Хорошая программа приносит разработчику деньги, как стимул продолжать разработку. К тому же, когда контроль над разработкой и развитием ведётся одним человеком - оно как-то спокойнее. Группа со-разработчиков, предлагающих идеи и занимающаяся альфа-тестингом - хорошо. Но распыление кода - не очень хорошо для подобного проекта.
Можно провести эксперимент. Как известно, FAR с версии 1.80 ушёл в опенсорс. Мажорная версия TC была на этот момент 7.0. Давайте подождём до выхода TC 7.5 (по моим прикидкам это будет вторая половина 2009 года) и сравним количество и качество улучшений в том и другом менеджере.
Обещают уже в этом году (см. роадмап).
>тотал коммандер насколько я знаю только 32х битный
Нет, он ещё и 16-битный был до последней версии (для Win 3.1). Отсутствие 64-битного компилятора - не единственная причина, там вообще используется компилятор от второй версии Delphi - он даёт более компактные и быстрые бинарники.
Ещё одна причина, по которой переход на 64 бита для TC затруднён - изменения в плагиновом API. Придётся переписывать сотни существующих плагинов, а многие авторы их уже давно не поддерживают.
Да и не будет для TC никакой выгоды от 64 бит. Разве что CRC будет быстрее считать, да плагины, которые большие объёмы данных обрабатывают, будут чуть быстрее работать (при условии, опять же, что и их портируют).
> А вот у опенсурса все гораздо лучше, фрипаскаль и соответственно лазарус умеют 64 бита не только нативно, но и кросскомпиляцией, так что это беда программиста, что он облажался при выборе языка.
Не могу сказать про это ничего. Ни разу не видел ни одного стоящего приложения, скомпиленного тем или другим.
Но вообще уходим мы от темы. Я своим первоначальным постом хотел сказать лишь, что винить программиста - глупо. Подождите, 64 битный софт года через три-четыре возьмёт своё. 32 бита тоже не сразу пришли - 386 процессор эвона когда появился, а 16-битный софт только со времени 95 винды стал исчезать (да и то, только к XP пропал почти совсем).
Я не могу сказать, за счёт чего идёт выигрыш во времени загрузки. Но вполне допускаю, что там может быть какая-то оптимизация. Но опять же - тут раз на раз не приходится. Могу предположить, что большинство обычных программ, используемых на оыбчном десктопе от 64-битности ничего не выиграют.
Кстати, как-то баловался с Suse 32 и 64 - разницы не видел никакой...
- Переписывать под 64 bit имеет смысл только приложения, которые реально могут это преимущество использовать. Т.е. софт, занимающийся какими-то расчётами. Для пользователя это могут быть программы кодирования мультимедиа, обработки 2D/3D графики... да и, пожалуй, всё. Тот же Skype вряд ли выиграет в производительности.
- Не всё зависит от программиста. x64 компиляторы есть далеко не для всех ЯП, и, даже если нужный компилятор найдётся, портирование перекомпиляции.
Таким образом, знания программиста, и тем более его финансовые возможности имеют довольно слабое отношение к нехватке x64 софта.
Но точно уверен, что никакого трояна там нет (в оригинальной дистрибутивной библиотеке, имею в виду).