Читал где-то - советские станции фобос не долетели до цели как раз потому, что часть команд была в восьмеричной системе запрограммирована, часть - в десятичной.
Ну и напутали в итоге...
Инфо о месте на хард диске
- Автор темы Chehov
- Дата начала
Читал где-то - советские станции фобос не долетели до цели как раз потому, что часть команд была в восьмеричной системе запрограммирована, часть - в десятичной.
Ну и напутали в итоге...
Если зависит от контекста, то однозначно:
- если B это Байт, то 1024MB;
- если B это Батон, то 1000MB.
Если не поняли, что такое контекст, то поясню - это то, в какой среде употребляется, т.е. с какими единицами, - и если это биты и байты, то однозначно 1024.
Теперь Вам задачка: Если В это вагон, то 4КВ это сколько? Интересно, запутаетесь?
И на засыпку, вопрос N2: Один цент это сколько? Ответите?
Прошу привести примеры, где шалости производителей винчестеров привели к ошибкам в "софтописательстве". Я лично, пока не смог придумать ни одного и весьма заинтригован. Для меня это будет солидным аргументом в пользу введения новых единиц.
А Вы действительно уверены, что здесь одни филологи?
Приведите, в конце концов, пример ошибок програмистов, пожалуйста, как реальный аргумент. Иначе все это с Вашей стороны пустая демагогия.
Последнее редактирование:
@Hron, не надо батоны придумывать, речь про то сколько байтов в 4 GB.
Так сколько?
И по софту, какими знаниями вы обладаете? Я же написал класс ошибок. Мало? Непонятно?
И причем тут шалости винтов? Зачем слова из контекста вырывать. Речь про использование не по назначению.
Программисты ленивый народ, очень часто берется готовое и допиливается, но часто берется совсем не то, что нужно, и вместо новой красивой понятной вещи получается франкенштейн.
Так сколько?
И по софту, какими знаниями вы обладаете? Я же написал класс ошибок. Мало? Непонятно?
И причем тут шалости винтов? Зачем слова из контекста вырывать. Речь про использование не по назначению.
Программисты ленивый народ, очень часто берется готовое и допиливается, но часто берется совсем не то, что нужно, и вместо новой красивой понятной вещи получается франкенштейн.
Простите великодушно, наверно я слишком запутанно написал. Ну что ж... Для Вас - любой каприз, не поленившись взять калькулятор, посчитаю дальше до байта - 4294967296 байт.
Дык с чем ошибки, кроме как с емкостью отформатированных винчестеров?
Если кто-то ленивый берет совсем не то что нужно, может заменить его на более удачливого и дееспособного? Только причем здесь K, M и пр... Поясните, если не ленитесь.
Знаниями, достаточными на бытовом уровне. Пописывал и дизасемблировал, пользовал Фортран, Ассемблер, С++, С#, Бейсик(MS Access). Не профессионально конечно, ну хобби было когда-то. Так что пишите смело - разберусь потихоньку.
Перечитал топик, простите, где? Не могли бы описать класс ошибок программистов ("софтописатели" это же они?), происходящих из-за того, что производители винчестеров КБ считают как 1000Б, ну и привести примеры еще раз - не могу найти(
Последнее редактирование:
Я даже больше скажу -- это всего-навсего 0xFFFFFFFF (на всякий случай -- считается от нуля). 32 адресные линии. 0xFFFF страниц по 0xFFFF байт. Или 0xFFFFFF секторов по 0xFF байт. Ни при разработке ПО, ни тем более при разработке железа и firmware для него новые единицы ничего не улучшают и ничем не помогают, поэтому новый мертворожденный стандарт нигде практически и не используется (подтверждаю как очевидец, я разработчик hardware и firmware, делаю то, что вы будете покупать лет через пять). Если есть психологическое затруднение, то лучше просто считать, что в недовешенном метрическом терабайте недовешенное -- это резерв на замену сбойных секторов. Это ничего не изменяет, но при ощущении несправедливости спать станет спокойнее.
Вот с винтами и не сходится, сами же понимаете, а строите из себя удивленного мальчика. Пока только с винтами, а что завтра будут в разных GB измерять, если всем начхать на стандарты? А если завтра еще какие-нить значения на эти приставки навесят в другой области?
Как и везде, хороших специалистов всегда мало. Поэтому часто заменить просто не на кого, и тянется легаси до упора.
@sepuka, так я и писал, что стандарт был слишком поздно принят, когда костыли уже прочно вошли в жизнь, и сейчас уже крайне сложно это менять.
Вот поэтому и есть в айти К, М, Г, которые не 1000 как положено, а 1024, да и то не везде.
Если бы все было хорошо и замечательно, то откуда бы появился этот топик?
Можете дискутировать и дальше. Я уже достаточно написал. Я за единообразие в обозначениях.
Если вы хотите, чтобы в каждой области все приставки были разными, это ваше право хотеть. Ломать старые устои всегда трудно.
@Eugene Ego, мальчика?!.. Далеко пойдете)))
Но я действительно не понимаю, как маленькая хитрость производителей ЖД может привести к фатальным ошибкам профессионалов, тем более к ошибкам в программах... Ошибки из серии "Ах, ну да..." не считаются.
Дык, приведите пример ошибки програмиста и программы, в которых объем с наклейки винчестера привел к фатальной ошибке? Тем более их, примеров, у Вас ух сколько... Делитесь!) Иначе - балабол.
А топик появился лишь из-за того, что не сделали единственно возможной величину 1024 для килобайта. Но кроме как досады работников службы поддержки торговцев жесткими дисками ежедневно и у простых смертных раз в несколько лет, других неудобств ни у кого не вызывает.
А Вы, любезный, не в службе поддержки работаете? Хотя, даже в этом случае, Ваши утверждения - полная глупость, ведь выяснять и разъяснять придется в несколько раз больше)))
Но я действительно не понимаю, как маленькая хитрость производителей ЖД может привести к фатальным ошибкам профессионалов, тем более к ошибкам в программах... Ошибки из серии "Ах, ну да..." не считаются.
Дык, приведите пример ошибки програмиста и программы, в которых объем с наклейки винчестера привел к фатальной ошибке? Тем более их, примеров, у Вас ух сколько... Делитесь!) Иначе - балабол.
А топик появился лишь из-за того, что не сделали единственно возможной величину 1024 для килобайта. Но кроме как досады работников службы поддержки торговцев жесткими дисками ежедневно и у простых смертных раз в несколько лет, других неудобств ни у кого не вызывает.
А Вы, любезный, не в службе поддержки работаете? Хотя, даже в этом случае, Ваши утверждения - полная глупость, ведь выяснять и разъяснять придется в несколько раз больше)))
Вы перегибаете палку, и банально хамите, вы уже, видимо, далеко пошли. Вы же сами пишете, что есть уже два гигабайта.
Если уж интересно, то разработчик с 10-летним стажем, от микроконтроллеров до энтерпрайза и айфонов. А вы так и не удосужились себя описать. Видимо совершенно далеки от айти, да и от приличного общения.
Есть префиксы СИ, о каких единых 1024 может идти речь?
Вот тут в конце есть интересная заметка "Historical context" http://physics.nist.gov/cuu/Units/binary.html , там даже про третий мегабайт есть.
Если уж интересно, то разработчик с 10-летним стажем, от микроконтроллеров до энтерпрайза и айфонов. А вы так и не удосужились себя описать. Видимо совершенно далеки от айти, да и от приличного общения.
Есть префиксы СИ, о каких единых 1024 может идти речь?
Вот тут в конце есть интересная заметка "Historical context" http://physics.nist.gov/cuu/Units/binary.html , там даже про третий мегабайт есть.
@Eugene Ego, два гигабайта - угу, на наклеках дисков и на всем другом)))
Каких единых? Ну вопрос о центе вы проигнорировали)))
PS. По службе прочно связан с ИТ дирекцией одной из крупнейших российской компании. Понтересовался спецом для Вас - за последние десять лет не возникло ни единственной не то, что бы проблемы, но вообще вопроса, связанного с размером КБ...
И, извините, это ж какими способностями надо обладать, что б допускать ошибки с размером килобайта при программировании микроконтроллеров и пр., мне не дано осмыслить) Примеров от Вас, я так понял ждать уж не приходится, так что увы...
Каких единых? Ну вопрос о центе вы проигнорировали)))
PS. По службе прочно связан с ИТ дирекцией одной из крупнейших российской компании. Понтересовался спецом для Вас - за последние десять лет не возникло ни единственной не то, что бы проблемы, но вообще вопроса, связанного с размером КБ...
И, извините, это ж какими способностями надо обладать, что б допускать ошибки с размером килобайта при программировании микроконтроллеров и пр., мне не дано осмыслить) Примеров от Вас, я так понял ждать уж не приходится, так что увы...
Последнее редактирование:
Ну да, уже минимум три поколения живут с этим, привыкши. А костылей на самом деле никаких нет, все возможные коллизии именно с этой стороны были решены ещё во времена Алгола и Кобола, это 60-е годы прошлого века прошлого тысячелетия, ежели чего. Помню, бо в детстве крал у мамы книжки про эфто дело с верхней полки шкафа, научили читать в 4 года на свою голову. Чтобы накосячить именно с этой стороны, надо обладать особым индусским складом мышления, гораздо чаще встречается другая проблема, действительно настоящая -- кое-где за пределами США местами успела распространиться метрическая система и бывают коллизии при переводе на неё с нормальной человеческой дюймовой, которой мы пользуемся со времён мезолита, а вероятнее всего, ещё с палеолита.
@Hron, перечитайте мои сообщения и осознайте, то о чем я писал.
Я обобщал проблему костылей от неверного выбора в программировании.
Но вот конкретно по проблемам размеров, спешл фо ю:
- наш любимый обсуждаемый размер дисков: на наклейке в десятичных написан, но в винде он пишется в двоичных, в макоси же таки в десятичных.
- не очень давно встретил систему некорректно считавшую допустимый размер файла подаваемого на вход, пользователю говорилось, что он может загрузить 100 MB, но фактически считались десятичные мегабайты, и пользователь не мог загрузить 100 мегабайтный файл.
- не так давно пользователи пытались засудить эппл за то, что мол размер внутреннего хранилища не соответствует надписи, хотя там больше о том, что какое-то место система сама занимала, но тоже рядом.
Причем тут цент? Мы про приставки СИ говорим. Есть приставка centi - сотая часть.
@sepuka, если бы не было проблем, то стандарт даже и не подумали бы принимать. Логично же?
Я обобщал проблему костылей от неверного выбора в программировании.
Но вот конкретно по проблемам размеров, спешл фо ю:
- наш любимый обсуждаемый размер дисков: на наклейке в десятичных написан, но в винде он пишется в двоичных, в макоси же таки в десятичных.
- не очень давно встретил систему некорректно считавшую допустимый размер файла подаваемого на вход, пользователю говорилось, что он может загрузить 100 MB, но фактически считались десятичные мегабайты, и пользователь не мог загрузить 100 мегабайтный файл.
- не так давно пользователи пытались засудить эппл за то, что мол размер внутреннего хранилища не соответствует надписи, хотя там больше о том, что какое-то место система сама занимала, но тоже рядом.
Причем тут цент? Мы про приставки СИ говорим. Есть приставка centi - сотая часть.
@sepuka, если бы не было проблем, то стандарт даже и не подумали бы принимать. Логично же?
Во, сгенерил критическую ошибку, которая возникает из-за производителей. И соответствующую задачу:
Искуственный спутник обращается вокруг земли. Со спутником устанавливается один сеанс связи за оборот. Количество информации, собираемой спутником за один период и подлежащий передаче на землю составляет 4294967296 байт. Програмист пишет программу кэширования данных на жесткий диск для последующей потоковой передачи на землю, а так же дает задание на приобретение жесткого диска размером 4ГБ.
Спутник выводится на орбиту и успешно умирает на первом обороте всвязи с переполнением винчестера.
Найдите в этой задаче двух тупиц и одного дебила.
[DOUBLEPOST=1430686812,1430685886][/DOUBLEPOST]
Искуственный спутник обращается вокруг земли. Со спутником устанавливается один сеанс связи за оборот. Количество информации, собираемой спутником за один период и подлежащий передаче на землю составляет 4294967296 байт. Програмист пишет программу кэширования данных на жесткий диск для последующей потоковой передачи на землю, а так же дает задание на приобретение жесткого диска размером 4ГБ.
Спутник выводится на орбиту и успешно умирает на первом обороте всвязи с переполнением винчестера.
Найдите в этой задаче двух тупиц и одного дебила.
[DOUBLEPOST=1430686812,1430685886][/DOUBLEPOST]
В каком месте пишется и где используется? Если вывод инфо, то винда выводит также и просто в количестве байт. Безо всяких модификаторов. Пока ничего критичного.
Либо, что напрашивается, такова постановка задачи и ТЗ от какого ни будь барыги-хостера или онлайн помойки, либо дурак програмист, который дополнительно приложил усилия для перевода двоичных данных в десятичные и обратно, но не лентяй... Незачет
Там исключительно из-за уменьшеного размера доступного пользователю места за ччет выделяемого под систему - Незачет.
А мне сдается, что цент равен 0.00058 ...
Последнее редактирование:
@Hron, размеры файлов везде округляют до ближайших больших при выводе в общих списках. Факт в разнице испльзуемых приставок.
Пример с файлом - пример типичной лени и невнимательности, которая встречается все чаще и чаще. Исправлял я сам это.
Я не знаю какие у вас там центы, ибо это не относится к стандартизированным приставкам. Так что извольте приводить соответствующие примеры.
Кстати, про мак, давно не пользовался файндером, и вот жеж какая беда, файндер показывает и размеры файлов в десятичных приставках, а не двоичных. Что скажете? Эппл лохи?
Пример с файлом - пример типичной лени и невнимательности, которая встречается все чаще и чаще. Исправлял я сам это.
Я не знаю какие у вас там центы, ибо это не относится к стандартизированным приставкам. Так что извольте приводить соответствующие примеры.
Кстати, про мак, давно не пользовался файндером, и вот жеж какая беда, файндер показывает и размеры файлов в десятичных приставках, а не двоичных. Что скажете? Эппл лохи?
Эппл - барыги. И Вы знаете, кого Эппл пытается держать за лохов. Но неужели Вы думаете она пошла на принцип потому что есть СИ?!))) Ее подход к бизнесу вызывает ответную реакцию - и она вынуждена идти на поводу у производителей ХД, потому как указывает в спецификации объем дискового пространства - и тут могли бы быть казусы коммерческого характера. Но это просто инфо на экране - не вижу эффекта от этого более страшного, чем редкий вопрос какого ни будь любопытного... Я честно, не очень то и представляю себе обывателя - юзера мака, интересующегося размером файла. А критичность и беда то в чем? Ну если и не критичность, то к каким ошибкам программистов это может привести, если API выдает нормальный размер?
Честно с Вашей стороны пока не было ни одного примера, показавшего бы критичность ситуации и необходимость введения новых единиц... Сдается мне, что если кого-то коробит от куска мела, лежащего непараллельно доске, то доску совершенно необязательно разворачивать... Не?
Ну к своей задачке с критичной ошибкой вернусь (условия выше).
Ответ:
Тупица 1. - Тот, кто подготовил, согласовал ТЗ и передал его программисту.
Не предусмотрена возможность увеличения объема данных в буфере в т.ч. и из-за пропуска сеанса/ов по независящим от спутника причинам - условия связи, работоспособность наземной станции и т.д и т.п. Для повышения надежности объем буфера должен бы содержать гораздо больше информации... При учете данного момента спутник мог бы прожить весь отведенный срок.
Тупица 2. - Программист.
Им не предусмотрена деградация винчестера и появление сбойных блоков со временем, особенно в столь критичном приложении. При правильном подходе необходимый объем винта был бы достаточен хотя бы для непродолжительной эксплуатации.
Дебил - Испытатель.
Тестировать готовую систему надо на реальных компонентах и в приближенных к реальности условиям, чего не было сделано, т.к. в противном случае проблема всплыла на первом же цикле обмена. Из этого следует что на тест либо подцепили другой винт, большего размера, либо использовали меньший объем данных. И то и другое - фейл.
Но надо отдать должное, что такое количество монстров сообща способно завалить любой проект, даже тот, в котором винты не используются... Хотя, если б на винтах указывали корректный размер, то спутник хоть один оборот, но, скорее всего, сделал бы.
@Hron, да нет никакой критической ошибки, откуда вы ее берете? Вам просто больше зацепиться не за что?
Есть периодически надоедающая проблема разности в трактовке единиц измерения информации.
То что она есть - это факт.
И то что две доминирующие на рынке оси по разному отображают размер файлов - это не нормально. Ненормально и то, что стандартизирующие организации никак не могут на это повлиять.
Вы думаете эппл вынуждена идти на поводу у производителей винтов? Вы очень сильно недооцениваете эппл, это они могут диктовать, если им надо будет.
По поводу разработки, вы видимо очень далеки от процесса софтописательства.
Ну и ваши выражения про типиц и дебилизм - это верх политкорректности, и очень вас красит.
Вот в разработке под маки как прикажете переводить размер, если система отображает в десятичных? А если софт кроссплатформенный?
Есть периодически надоедающая проблема разности в трактовке единиц измерения информации.
То что она есть - это факт.
И то что две доминирующие на рынке оси по разному отображают размер файлов - это не нормально. Ненормально и то, что стандартизирующие организации никак не могут на это повлиять.
Вы думаете эппл вынуждена идти на поводу у производителей винтов? Вы очень сильно недооцениваете эппл, это они могут диктовать, если им надо будет.
По поводу разработки, вы видимо очень далеки от процесса софтописательства.
Ну и ваши выражения про типиц и дебилизм - это верх политкорректности, и очень вас красит.
Вот в разработке под маки как прикажете переводить размер, если система отображает в десятичных? А если софт кроссплатформенный?
Эппл не идет на поводу, а с удовольствием подхватывает инициативу, которую еще и не надо защищать перед сообществом... Ну барыги с удовольствием перенимают опыт друг друга! Это нормально, ужели не понятно?))
Поясните, плз, почему введение новых единиц исправит ситуацию? Неужели то, что длина файлов в Винде будет показываться в "ибибайтах", т.е. те же цифры с просто измененными обозначениями, а на винтах и макоси по-прежнему в десятичных Килобайтах (т.е. вообще без изменений), действительно решит какую-либо проблему и избавит Вас от беспокойства? Ведь сами цифры в отображении размера не изменятся и по-прежнему будут разные. Честно говоря не совсем представляю, что для Вас изменится коренным образом? Объясните.
[DOUBLEPOST=1430742263,1430741520][/DOUBLEPOST]
Я, вроде, не представлялся программистом...
Про тупиц и пр. - а что Вас там так задело, нечто знакомое? И как по Вашему квалифицировать сотрудников, допускающих подобные промахи в ответственных проектах? Таких гонят мокрыми тряпками.
Неужели у человека "технического математического" возникают трудности перевода из десятичной системы в двоичную и обратно? Порекомендую ознакомиться с логарифмами. А если нужна точность, то обе системы выдают длину и в байтах... В чем проблема?
PS. Из любопытства за пять минут нашел костыль для OS Х, который меняет базу в отображении длин файлов... Ну воспользуйтесь, если это так отягчает жизнь.
Последнее редактирование:
Таких как вы надо гонять тряпками, ибо они и набирают таких программистов, и не удосуживаются организовать нормальный рабочий процесс, а вместо этого тупицами и дебилами называют и поливают грязью. Потому как сами недалеки умом.
Вы бы опять удосужились прочитать мои сообщения, ибо написано же, что файндером не пользуюсь. И поэтому практически не наблюдаю этого на маке.
У меня нет проблем с переводом, у меня даже часы на руке бинарные. знаете ли. Уже не раз выше было написано, что мне не нравится и не устраивает, но видимо вам просто не под силу это прочитать и осознать.
P.S. Я думал, что тут все-таки собираются достаточно интеллигентные люди, могущие выслушать, аргументировано обсуждать, но я ошибался, глупость и хамство неистребимо.
@Eugene Ego, ну так и вместо того, что бы пытаться перейти на личности, поясните хотя бы, плз, аргументированно, как введение новых единиц исправит ситуацию?)
PS. Задачка просто придумана от и до, что бы представить какую либо ситуацию, где неправильно понятый размер винта имеет критическое значение. Любые сходства чисто случайны.
PS. Задачка просто придумана от и до, что бы представить какую либо ситуацию, где неправильно понятый размер винта имеет критическое значение. Любые сходства чисто случайны.
Последнее редактирование: