Balancer: Все сообщения за 4 Января 2017 года

TEvg-2> Можно найти линукс который не знает вебку. Но я могу взять и поставить другой линкс, в котором все будет хорошо. А взять и поставить другой ведроид в котором все будет работать я не могу.

Зачем другой ведроид, когда можно просто собрать ядро с нужными тебе драйверами? Android «внизу» — это Linux. Со всеми вытекающими. Все претензии к Android на уровне поддержки железа или протоколов — это претензии к Linux.

•  инфо
•  инструменты
• Ответить на сообщение

tarasv> Бери гугловсую IDE если хочется в один клик, она сама все нужное поставит.

Ему не хочется в один клик. Ему хочется ныть А тема для нытья находится всегда разная Вот в этот раз — Android.

•  инфо
•  инструменты
• Ответить на сообщение

tarasv> Схема, упрощенно, такая - с каждого проданного устройства Гугл имеет прибыль. Допустим 25% от продажной цены (в реальности скорее всего меньше). В данно конкретном случае Гугл через фонд дает не сами устройства, а деньги на их покупку, поэтому не надо пытаться посчитать от себестимости устройства, накладные расходы в нем такие-же как и при обычной продаже. Сделав взнос в $1000 на закупку своего оборудованиея Гугл потратил $750. Теперь его бухгалтер уменьшает прибыль компании на $1000 которые были вложены в благотворительный фонд и получает уменьшение корпоративных налогов на $350 (при их доходах у них ставка корпоративного налога 35%) итого чистые расходы Гугла на благотворительность $400.

Вот! А теперь представь, что Google выделяет деньги не на свой товар. Тогда он тратит $1000 на благотворительность, получает снижение налогов $350 и имеет потерю в $650. А не $400, как в твоём случае. Те самые $X = 250 разницы (пусть реально и меньше), которые выше отказался комментировать Мишка Если расходы на благотворительность фиксированы то эти $X получаются самостоятельным бонусом. Поэтому Гуглу выгоднее финансировать благотворительными взносами покупку собственных гаджетов.

•  инфо
•  инструменты
• Ответить на сообщение

Mishka> Гугль в первую очеред покрывает расходы на себестоимость, а потом сверху — прибыль. Поэтому от продажи он получит прибыль. От того, что он даст 200 на покупку у себя, или просто бук — нет, прибыли не получит, т.к. себестоимость не покрыта.

Так что, Гугл продаёт Хромобуки по себестоимости?

Mishka> Вот с теми цифрами — себестомость 150, прибыль 50, всего 200. Если он дал 200, то 50 получил назад, а 150 потерял.

Нет, ты не понимаешь. Сколько он дал — это отдельное, не связанное с Хромобуком потеря. Он их всё равно отдаст на благотворительность. Не важно, на Хромобуки или на канцтовары. Это уже, скажем так, неизбежная потеря. Поэтому покупка или не покупка Хромобука на эту потерю не влияет. Зато если он купить канцтовары, то он не получит эти $200-$150=$50 прибыли с продажи одного Хромобука. Да, суммарный баланс продажи вместе с благотворительностью может быть отрицательный. Он этот баланс будет меньше чем при благотворительности на канцтовары.

При покупке канцтоваров Гугл теряет $200_благотв.

При покупке Хромобука Гугл теряет $200_благотв - ($200_цена - $150_себест) = $150.

Поэтому благотоврительность, направленная на покупку собственного товара выгоднее (прямо, а не косвенно), чем отданная на покупку чужого товара.

Mishka> И? Где новые клиенты Гугеля? Поэтому Гугелю канцтовари неинтересны. Я же тебе с самого начала и сказал — Гугель и я сами выбираем кому давать, а кому нет.

Так с этим я не спорю. Но это совсем другой вопрос.

Mishka> Просто продажа — да. Пожертвование — нет. Что тут не понятно? Если он дал 200 на покупку у себя, то он потерял 150.

А если отдал $200 на покупку на стороне, то он потерял $200. Вот эти $50 — и есть выгода Гугла от покупки собственного товара, а не стороннего.

Mishka> Дык, нет там прибыли. Я тебе про это пишу с самого начала. И поэтому первый пункт — чистое враньё.

Гугл при покупке у себя теряет $150. При покупке на стороне — $200. Покупать у себя на $50 выгоднее. Что не так? И, да, для математика ты очень вольно обращаешься с исходными заявлениями. Про «прибыль» там вообще не было ни слова. Цитата:

Деньги, потраченные на благотворительность, частично возвращаются в Google (это 1).

 

Между «прибыль» и «деньги частично возвращаются» для тебя нет никакой разницы?

Mishka> Слушай, я в этом деле кручусь. И дочка эти потоки считает.

Да хоть ты Сергеем Брином будь. Это не отменяет чистой арифметики, которую ты почему-то в упор отбрасываешь

Balancer>> Вот. И если бы не было Гугла, то распределяли бы эти гигабаксы уже другие бы конторы. О чём я с самого начала и пишу.
Mishka> Не распределяли бы. Распределять могут только то, что заработано.

Вот тут тоже тебя переклинило. А что, кроме Гугла другие компании не могут ничего заработать?

•  инфо
•  инструменты
• Ответить на сообщение

Mishka> Извини, Рома, но это твоя "чуйка", которая не соответствует действительности. Нет там никаких +$X. Просто нет.

Зачем Гугл занимается благотворительностью если это ему ничего не даёт?

•  инфо
•  инструменты
• Ответить на сообщение

V.Stepan> Да, конечно. Едет пассажирский поезд, за 5 минут до перевода часов вперед он прибывает на остановку по расписанию, потом ч/з 20 минут у него другая остановка, а часы скакнули на час вперёд.

Что-то тебя совсем не в ту степь унесло.

Вот, как твой метод решает такое веселье?

•  4
•  инфо
•  инструменты
• Ответить на сообщение

PSS> Спор, ради спора?

Нет. Спор с неверными утверждениями.

Balancer>> Если не считать неравенство физическому времени, которое не имеет отношения к разрядности, то какие там ещё есть проблемы?
PSS> А вот этого "не считать неравенство физическому времени" мало?

Ещё раз перечитай внимательно на что отвечал. Я спорю с претензиями к якобы неучёту разрядности. Какое отношение к этой якобы проблеме имеет неравенство физическому времени?

Balancer>> Какие костыли и как увидеть ошибку?
PSS> Вот, например, у ssb

Это НЕ «проблема» разрядности.

PSS> Уверены? Кстати, скажем, на 10 октября 1582 года, он что выдаст?

Что и положено, воскресенье. То, что григорианский календарь начинается от 15 октября, не отменяет того, что он может указывать и 10 октября 1582.

PSS> Отклонение от УТС

Не имеет отношения к разрядности.

PSS> Я обсуждаю обе проблемы. Нельзя?

Можно. Но про несоответствие физическому времени я сам написал сразу же. Поэтому, очевидно, что спорю я только с «проблемой» разрядности. Которая давно не проблема.

PSS> Сейчас проблема с разрядностью ушла

Это противоречит тому, что ты всё время писал в теме и с чем я, собственно, и спорю.

> Собственно когда в 1970 водили Юникс время явно многое не додумали. От сложности отображения более ранних дат, то проблемы 2038 года. И теперь это проблема.

>> Balancer> В моих системах «проблемы 2038» давно уже нигде нет...
> В 2038 году проверим.

> Здесь работает. А на мандрива (если не путаю, пару лет прошло) нет.

> И проблемы есть сейчас, а не тогда когда исчерпает 64 битный код.

•  7
•  инфо
•  инструменты
• Ответить на сообщение

V.Stepan> У меня вообще никакого метода нет . У меня есть утверждение, что скачки "летнее/зимнее" приносят проблемы

Это проблемы только пользователей, но не разработчиков/диспетчеров/машинистов И, да, вот у пользователей — вполне себе проблема. Сколько народа опаздывало на работу, на поезда, на самолёты... Но проблемы «поезду нагнать время» это не создаёт Поезд уходит по одному времени, приходит по другому. Абсолютно то же самое, что с пересечением часовых поясов.

Когда самолёт летит из Москвы в Калининград, то путь занимает один час. Когда из Калининграда в Москву — три часа. Значит ли это, что он в Калининград летит в три раза быстрее, чем из Калининграда?

Вот когда время переводили, было то же самое, только два раза в год.

И точно также было на ЖД, когда в расписании писали местное, а не московское время.

Между прочим, переход на московское время проблему не решил. Хаоса с точки зрения пассажиров, пересекающих часовые пояса ничуть не меньше. Потому что на часах показано местное время, а в расписании — московское. И пассажиры нередко всё также приходят по местному. Когда поезд уже ушёл Или, наоборот, приезжают по московскому времени к самолётам. Которые летают по местному времени

•  4
•  инфо
•  инструменты
• Ответить на сообщение

stas27> ОК, отдаёт 200 у.е., получает назад 50... Ну да, ясен пень, выгода.

Что выгоднее при прочих равных, потерять $200 или потерять $150? И, на всякий случай повторю, фраза, с которой до сих пор спорит Мишка, звучит как «Деньги, потраченные на благотворительность, частично возвращаются в Google (это 1)»

Balancer>> На самом деле не важно, какую конкретно выгоду Гугл получает с благотворительности. Важно, что она есть. Иначе бы он ею не занимался.
stas27> Очень верное замечание, КО! Абсолютно согласен.

Ну, не знаю, Мишка, вот, с этим не согласен. Он говорит, что нет никакого +$X

stas27> Ну ОК, ещё из 200 (из нашего примера) получит ещё 25... нет, 50, что их, басурман, жалеть. Отдал 200, получил назад 100... Прямая и непосредственная, однозначно считаемая выгода, что уж там

Ага. $100 выгоды по сравнению с чистой потерей $200. Что не так? Если что, «выгода» != «чистая прибыль».

«Выгода. — польза, преимущество. Получить много выгод. Думать о своей выгоде.»

stas27> Ром, ну вот просто покажи на разбираемом там примере

За сложными цифрами подобных примеров скрывается простая суть банальной арифметики. В твоём примере для Гугла есть разница (сугубо финансовая), купит он на выделенные деньги скотч от 3M или Хромбуки от HP? Если вынести за скобки благотворительный взнос, снижение налогов, имиджевые бонусы и т.п., которые будут равными в обоих случаях, то что, и от скотча, и от Хромбуков Гугл равно ничего не получит? Или же ему капнет какая-то денежка от продажи Хромбука?

•  2
•  инфо
•  инструменты
• Ответить на сообщение

TEvg-2> Я не роняю винты каждый день. Достаточно уронить раз в год и хана.

А зачем его раз в год ронять? Первый винчестер, с которым я работал, у меня появился в 1991 году. Затрудняюсь оценить, сколько за эти годы их прошло через мои руки. Сотни, наверное. И я, будучи на самом деле, весьма криворуким и неуклюжим, ни разу ни один винчестер не уронил. Что я не так делаю?

TEvg-2> Практически установленно ДВД в пакетиках царапаются реже, чем бьются винты.

Практически установлено, что DVD накрываются массово через несколько лет лежания в коробках даже без всякого царапания. И что НАМНОГО хуже, обнаруживается это ТОЛЬКО когда диск оказывается нужным и ты пытаешься его проиграть

Чтобы у меня накрылся лежащий на полочке винт — такого не бывало вообще пока. А проблемы работающего винта обнаруживаются сразу и он спокойно меняется на другой, данные восстанавливаются с зеркала.

•  2
•  инфо
•  инструменты
• Ответить на сообщение

TEvg-2> Он не голый. Он прикручен винтами к системнику. И упал вместе с системником.

Ну, если так глубоко копать, то винты лучше переносят пожары, чем DVD!

•  инфо
•  инструменты
• Ответить на сообщение

Monya> Если б в момент падения в DVD приводе крутился диск, то скорей всего ты б лишился и привода и диска.

Гы. Бывали случаи (неоднократные!) у знакомых, когда CD/DVD разлетались в приводе при простой штатной работе Последний случай, вроде, у Aaz'а был

Monya> наверняка б соскочила с креплений в приводе и проехалась бы по лазеру

Нет, разлёт при вращении — это веселее. Иногда тупо переднюю планку осколками вышибает

•  1
•  инфо
•  инструменты
• Ответить на сообщение

V.Stepan> Нет, ему надо в стандартный график вернуться, поэтому активно "нагоняет", чтобы, по возможности, прибывать стандартно.

Какой «стандартный график», если время перевели? Я же привёл пример с полётом из Москвы в Калининград. То, что в одну сторону путь занимает один час, а обратно — три часа, не значит, что самолёт в одну сторону «нагоняет», а обратно «плетётся» Он и туда, и обратно летит с одной скоростью. Также и с поездами при переводе времени. С какой скоростью поезд ходил, с такой и дальше пойдёт. Потому что расписание при переводе времени тоже корректируется. Вот если бы время перевели, а расписание осталось старым — тогда да, пришлось бы нагонять или стоять

•  1
•  инфо
•  инструменты
• Ответить на сообщение

>>Сумма всех нечетных простых чисел...
Mishka> Но 2 точно туда входит.

2 — нечётное?

•  2
•  инфо
•  инструменты
• Ответить на сообщение

stas27> Ну тогда и спорить не о чем.

Ну, не знаю. Мишка, вот, спорит

>> Деньги, потраченные на благотворительность, частично возвращаются в Google (это 1)

Mishka> Пункт 1 — чистое враньё. Гугель не получает денег с пожертвований.

 

stas27> Остаётся в сухом остатке только то, что ты считаешь эти операции Гугля бесчестными и мозгопромывающими

Не-не. Где я такое утверждал? Я писал, что Гугл основательно промывает мозги, но это утверждение не имеет ничего общего с темой возврата части средств от благотворительности. Это совсем другая история.

stas27> Гугль вполне может сам решать, как и чем ему помогать школам.

С этим я тоже нигде не спорил.

•  1
•  инфо
•  инструменты
• Ответить на сообщение

PSS> Тогда внимательно читайте, что скажет собеседник. И не пишите, что текущий метод при 64 битной разрядности может вычислить верную дату на миллионы лет.

Тогда внимательно читайте, что скажет собеседник. Я нигде не писал, что unixtime (это с несоответствием-то реальному времени!) вычисляет верную дату на миллионы лет. Я писал, что проблем с разрядностью не будет на сотни миллиардов лет.

PSS> Да, но при этом приводя доводы вроде

А что не так? 64 бит не хватит для адресации 500+ млрд. лет?

PSS> В которых проблема с отклонением от физического времени встает в полный рост.

Но проблема отклонения не имеет никакого отношения к проблеме разрядности. Проблему отклонения я сразу назвал и с ней не спорю. Я спорю с выдуманной проблемой разрядности. Которой, во-вторых, сегодня уже практически нет, а во-первых, это чисто проблема прикладной реализации, которая не была глобальной и решающей даже 30 лет назад.

PSS> Проблемы использования дат в 32 битной системе.

Это не проблема UNIXTIME. Это даже не проблема 32-х битной системы. Это проблема конкретных программистов, которые ограничивают счётчик времени 32 битами. Хотя прекрасно могут считать и 64 бита хоть на 8-битной системе.

PSS> Проблему отклонения от физического времени

Тут можно не ломится в открытую дверь.

PSS> Проблему дат до 1970 года

А тут какая проблема? Я не вижу тут проблемы. И в теме пока ничего конкретного на этот счёт не было -1 секунда — это 31.12.1969 23:59:59 UTC, -2 секунды — это 31.12.1969 23:59:58 UTC и так далее. Все так считают, всё прекрасно работает

PSS> Ну и оценка исторических дат

Ага. И проблема определения даты осады Трои — тоже проблема UNIXTIME?

PSS> А кто Вам сказал, что я обсуждаю ТОЛЬКО проблемы разрядности.

А потому что проблему неточного соответствия физическому времени я назвал сразу. И кроме как о выдуманных проблемах UNIXTIME с разрядностью тут я ни с чем не спорю.

PSS> Я обсуждаю Юникс-время и его слабые и сильные стороны. Может хватит приводить этот довод?

Тогда, если выбросить проблему разрядности, Вам придётся спорить о проблеме несоответствия физическому времени только с самим собой. Тут, вроде, никто с этим не спорит.

PSS> То есть тот факт, что в реальности в григорианском календаре такой даты просто не существовало Вас не смущает.

Метр придумали в 1790 году. Значит ли это, что мы не можем измерить в метрах марафонскую дистанцию?

PSS> не смущают фразы вроде

Не смущают. Потому что по юлианскому календарю дата распятия будет другая.

PSS> Кстати, здесь утверждают, что пятницей было 3 апреля
PSS> И, боюсь, лучше здесь самому все проверить.

Так не сложно же:

1 апреля 2017 = суббота
1 апреля 1933 = (6 - (117-33)*365 - [(117-33)/4])%7 = 6. Снова суббота. По календарю так и есть.
1 апреля 1033 = (6 - 900*365 - [900/4] + [900/100] - [900/400])%7 = 1. Понедельник.
1 апреля 0033 = (1 - 1000*365 - [1000/4] + [1000/100] - [1000/400])%7 = 5. Пятница.

По Григорианскому календарю так.

PSS> Но тогда нужно понимать, что это не шутки. И не приводить доводы, что все точно считается до ХХХХ года..

Я не писал точно. Я писал, что это не проблема разрядности. Читайте внимательнее.

PSS> Вовсе нет. Я просто упомянул про проблему 2038 года.

Я процитировал. В цитатах утверждается иное

PSS> Или проблемы с временем 64 бит, кроме отклонения от физического времени, есть еще проблема с более ранними датами.

В чём проблема с более ранними датами? Пока я так и не увидел примера такой проблемы.

PSS> То, что в некоторых системах она работает не значит, что она работает во всех.

Зато это значит, что это проблема не UNIXTIME, а кривых реализаций конкретных систем.

PSS> Кстати, проблема Андройда, как следует по статьям, была вовсе не из-за 32 бит. А из-за того, что его софт не работает с отрицательными датами.

Это проблема конкретной реализации конкретной библиотеки. Если кто-то криво будет считать отрицательные длины, значит ли это, что виновата система СИ?

PSS> Или Вы реально полагаете, что раз в Вашей ОС все работает, то все везде работает? И проблем нет?

Если у продавца криво работают весы, это не значит, что крива система СИ. Это значит, что проблемы у продавца или разработчика весов.

PSS> Если не хотите смешивать давайте разнесем темы выше по отдельным темам форума.

А смысл? Проблему несоответствия физическому времени я сам назвал сразу же и с ней не спорю. А проблемы разрядности или отрицательных величин одинаково надуманные. Нет этой проблемы у UNIXTIME. Это проблемы конкретных криворуких программистов.

•  2
•  инфо
•  инструменты
• Ответить на сообщение

V.Stepan> Он должен прибывать на станцию в 5 утра вне зависимости от того, какое сейчас время — зимнее, летнее или осуществлён переход.

А, тьфу, точно. Я забыл, что при переводе времени расписание не сдвигалось. Как в 5 утра приходил по летнему, так потом в 5 утра приходил и по зимнему. Сорри, тут ошибся

•  инфо
•  инструменты
• Ответить на сообщение

PSS> А здесь день недели определяется так

Ну да. Пятница. Дни-то недели по обоим календарям совпадают (для скорректированных дат).

Что 25.10.1917 по Юлианскому, что 07.11.1917 по Григорианскому — всё одно будет среда День-то один, только шкала измерения разная, а дни недели сквозные и неразрывные что по Юлианскому, что по Григорианскому.

•  2
•  инфо
•  инструменты
• Ответить на сообщение

Balancer>> А что не так? 64 бит не хватит для адресации 500+ млрд. лет?
PSS> Не хватит. Хватит только на вычисление некого числа

А то, про что я пишу — не число?

PSS>Просто потому, что уже через несколько десятков тысяч лет отличия реального времени от того, что будет выдавать Юникс согласно спецификации будет отличаться на дни.

Но это не проблема разрядности.

PSS> Просто вы в доказательство приводите доводы из совершенно других сфер. Из-за чего и весь сыр бор. Да в 64 битах можно уже подсчитать то, что нельзя было в 32 битах. Вот только неправильно подсчитать.

Да, но Вы постоянно упираете на проблему 32 бит. Которая не является проблемой UNIXTIME.

PSS> Вот с этим я готов спорить. Она изначально явно испортила много нервов и сил.

На счёт неточности времени? Согласен. На счёт разрядности? Это проблема не UNIXTIME, а криворуких программистов.

PSS> Просто хотел, чтобы Вы помнили об этом. А не рассчитывали время с разбросом в тысячелетия

За тысячелетия всё равно не наберётся погрешности на сутки.

PSS> Нет в спецификации.

В данном случае не принципиально. Прекрасно работает, адекватно воспринимается. Что ещё нужно?

PSS> Из-за чего нельзя изначально понять будут ли работать программа с отрицательными цифрами или нет. Или как будет работать.

Это проблема разрядности. То есть криворуких программистов. Не проблема идеи UNIXTIME.

PSS> См на глюк Андройда.

Проблема криворуких программистов.

PSS> Нет. Она куда более обширная. Вот почему, Вы решили что оценка даты распятия верна?

Это не проблема UNIXTIME.

PSS> Спорите. Это видно по примерам, что приводите. Распятие Христа и т д.

Я просто показываю, что UNIXTIME работает и для таких дат. Верность их вычисления (как и вообще спор о факте существования Христа) — вопрос, не имеющий отношения к UNIXTIME.

PSS> Ладно давайте обсудим отрицательное время. Как можно оценить верность работы с ним?

А как оно может быть неверным?

Balancer>> Метр придумали в 1790 году. Значит ли это, что мы не можем измерить в метрах марафонскую дистанцию?
PSS> Метры можем. Время - нет.

Приехали.

PSS> Так как марафонскую дистанцию бегут и сейчас, а исторические события остались в прошлом.

А я спрашиваю не про современный марафон, а именно про оригинальную версию. Хорошо, пример другой. Мы не можем измерять расстояние от Трои до Помпеи в километрах, потому что километр появился после того, как Троя пала?

PSS> Подобный расчет дает иллюзию, что мы хорошо представляем хронологию. Забывая о ограничениях что накладывает как физика так и календари.

Количество дней уже перестало быть целым числом, которое с высокой точностью можно отсчитать хоть на тысячу лет назад?

PSS> Уверены? Дело в том, что уже сам григорианский календарь точен только на периоды тысяч лет.

Один день погрешности на 10000 лет. В тех пределах, которые я рассматривал — этого достаточно. В любом случае, это опять не тот спор. Он не имеет отношения к «проблеме разрядности».

PSS> Ну а главное. Вы вычислили 1 апреля 33 года по Григорианскому Календарю. Но можете сказать, какае дата была на календарях в этот день?

Зачем? Я посчитал по современному календарю. Как и расстояние от Трои до Помпеи могу посчитать в километрах, а не в стадиях. Да, при оценке даты распятия Христа предполагается, что дни недели за прошедший период оставались сквозными, без разрывов. Но если это не так, то это не проблема Григорианского календаря. И уж тем более — не проблема UNIXTIME. Может быть Христа вообще не было UNIXTIME этим вопросом не занимается. Просто если Христос был, то по одной из оценок, не связанных с UNIXTIME, по Григорианскому календарю это была пятница, 01.04.0033. Повторюсь — это оценка независимая, никак не связанная с UNIXTIME. Так вот, UNIXTIME показывает, что этот день — пятница. Таким образом в рамках Григорианского календаря для прошедших дат UNIXTIME работает исправно. Всё остальное к UNIXTIME не относится.

PSS> Читайте внимательнее. Там уже не упоминалась проблема разрядность. Только проблема дат до 1970 года и исторических дат.

UNIXTIME с отрицательными числами соответствует Григорианскому календарю. Остальное к UNIXTIME отношения не имеет.

PSS> Вот только эта библиотека реализована строго в соответствии спецификации Юникса.

Нет. В определении не говорится об ограничениях разрядности. Это проблема реализации. То есть — криворуких программистов.

PSS> Вот только они так криво работают из-за того, что такая работа, грубо говоря, прописана в ГОСТе. Это нормально, по вашему?

В данном случае весы в рамках ГОСТа могут работать верно. Значит, если в этих рамках они работаю неверно, это проблема кривых рук производителя.

•  2
•  инфо
•  инструменты
• Ответить на сообщение

PSS> Вообще-то это Юлианский четверг. Пятница указанна иудейская.

Я показал пример, по которому при ручном расчёте по Григорианскому календарю данная дата — пятница. И эту дату не я выдумал, как и соответствие дню недели

•  инфо
•  инструменты
• Ответить на сообщение

VAS63>

Там YouTube, тут — цивильнее, картинками И в гораздо бОльшем объёме

•  инфо
•  инструменты
• Ответить на сообщение

Userg> Москву-Сити угадали, а вот котики-сиськи не просчитали

Тут урезанный вариант. Вот полный и в картинках —

•  1
•  инфо
•  инструменты
• Ответить на сообщение

TEvg-2>>А ДВД сам имею сотни.
D.Vinitski> ЫЫЫ!!! А можно объяснить - зачем???

Сотни DVD и у меня Ещё с тех пор, когда хранение на них стоило дешевле хранения на HDD. Другое дело, что в 90% данные на них уже устарели. Сегодня уже совсем убого смотрятся тогдашние рипы по 720Мб.

•  58
•  инфо
•  инструменты
• Ответить на сообщение

TEvg-2> Найди Штирлица в лучшем качестве, чем у меня

А что, «17-ю мгновениями» репертуар исчерпывается?

...

Вон, Холмс есть аж 1080p. И в нём видно много тонкостей, которых не видно в 480p. Например, в «Собаке Баскрвилей», в начальной сцене с отражением в кофейнике, с обкусанной тростью и т.п. То, во что на DVD приходится верить на слух (при чём я всю жизнь так и полагал, что так и надо ) в HD оказывается реально видно

А про современное кино — вообще молчу. То же 3D даже в 720p смотрится намного хуже, чем 1080p.

•  1
•  инфо
•  инструменты
• Ответить на сообщение

TEvg-2>> Найди Штирлица в лучшем качестве
D.Vinitski> А у тебя он в full HD?

Увы, такого в природе нет (кажется). Только DVDRip.

•  инфо
•  инструменты
• Ответить на сообщение

TEvg-2> Скажем Бриллиантовая рука у меня 8 ГБ на двойном ДВД.

На DVD качество по определению паршивое. DVD имеет низкое разрешение.




TEvg-2> С современными кинами высокого разрешения засада какая - большие, скачать трудно.

Это очень редкая частная проблема

TEvg-2> Ну а фильмы старые - их в высоком качестве никто не выпускает и редко это возможно, если они в исходнике такие были.

См. выше «Бриллиантовую руку» На DVD качество намного ниже, чем давала плёнка прошлого века.




TEvg-2> Нащет цен. Во-1 как ты признал раньше ДВД однозначно заруливали по цене.

Это было уже очень давно Сегодня HDD много дешевле. А ещё дешевле — облако (Amazon даёт безлимтиное хранилище за $5/мес).

TEvg-2> А ДВД записал - всё. Хороший, не очень, уже лежит и хранится.

У…

Дальше »»»

•  44
•  инфо
•  инструменты
• Ответить на сообщение

TEvg-2> Фильмы в каком качестве были в таком и остались.

Нет. Смотрим примеры выше Советские 720p НАМНОГО качественнее, чем DVD. Вот между 720p и 1080p разница уже почти неуловима (но есть). Поэтому я качаю 720p

TEvg-2> потом 720р. Есть 1080 - при случае перекачаю. Спасибо за наколку.

Именно для Холмса смысла нет. Я качал оба варианта, разницы между 720p и 1080p почти нет Нужно специально сравнивать покадрово, чтобы заметить.

А вот вместо старых DVD я 720p перекачал почти всё, до чего дотянулся

•  инфо
•  инструменты
• Ответить на сообщение

TEvg-2> А бывает такое - фильм в поганном качестве, но с отличной озвучкой. Воодушевившись скачиваешь высокое качество - и получаешь дерьмовую озвучку - Невезучие, в августе 44-го и др.

Пересобери. Делов-то на несколько минут Перекомпрессия не нужна. Видеоряд с одного видео, звуковая дорожка с другого. Это, конечно, если версия одинаковая.

•  1
•  инфо
•  инструменты
• Ответить на сообщение

Monya> Просто куда его сейчас?

Вот у меня в ящике стола сейчас валяются старые IDE. 80-120Гб. Штук 5. Работают. Но куда их?

•  2
•  инфо
•  инструменты
• Ответить на сообщение

TEvg-2> Капец. Рутракер это такое облако, только бесплатное.

Ну Рутрекере доступно только то, что интересно другим Домашнюю фотоколлекцию, скажем, на него не забэкапишь

Да и того гляди начнут штрафовать за закачки (а за поддержку раздачи торрентами могут и сейчас штрафануть). Придётся уходить в Darknet. А это скорости уже не позволяющие смотреть фильм в реальном времени. А из облака Амазона можно смотреть дома кино не выкачивая предварительно фильм, прямо оттуда

•  1
•  инфо
•  инструменты
• Ответить на сообщение

TEvg-2>> Капец. Рутракер это такое облако, только бесплатное.
D.Vinitski> С какой скоростью отдачи, ась?

Сейчас львиная доля фильмов позволяет смотреть их с торрента сразу, на лету. Я так даже на Android периодически смотрю. Секунд 10-30 на буферизацию, а потом смотришь как обычно.

Но, боюсь, такая халява скоро прекратится в связи с усилением антипиратских законов

•  1
•  инфо
•  инструменты
• Ответить на сообщение