Pull to refresh
Александр @Cobolorumread⁠-⁠only

User

Send message
Да знаю я о TI Sitara, но там ARM, а тут речь идет про MIPS. Если в качестве аргумента привести что то типа Vortex86 или AMD Geoge так там есть Все эти скоростные интерфейсы типа SATA или PCI. Но там опять же это то самый x86, но на этих процах есть готовые модули и платы (дороговато для DIY) но бери и используй под свои нужды. Проблем с интерфейсами под ними вообще нет.
Речь о том что нет на MIPS универсального процессора. А нас вся грузят нейроускортеями и т.п.
А как это делали во времена 3х пней?
Делали довольно просто: CPU-Northbridge-Southbridge
Понятно что CPU-NB реализовывать в двухчиповом варианте совершенно не современно, но нельзя прыгнуть через поколения. Закрепите интерфейсы что что бы они не меняли лет 5 и за это время все обрастет само собой.
Может 4 PCI-e это и сложно но дайте нормальные 2хPCI-e которые можно агрегировать ни в случаи нужды подключить их к PCI-switch. Но ни чего это нет, нам все время подсовывают или какие то Титаники или космические корабли. А нужны просто рабочие лошаки к которым можно без напряги цеплять хоть карету, хоть плуг. Intel PC поэтому и задавил всех что он дает универсальность пользователям.
Open source это хорошо, но есть ли MIPS:
-500-1000 МГц пусть даже один CPU, с загрузкой из SPI Flash
— где контролер памяти нормальный DDR3 с физическим SO-DIMM c поддержкой до 8Gb (даже пусть старшие 6 Gb будут в оконном/страничном режиме доступны)
— где наличествуют 2-4 шт. UART/SPI/I2C
— есть 2-4 таймера с возможностью вывода на прерывания
— И обязательно 2-4 порта PCI-E, на них подключат все сами, что хоть SATA, хоть Ethernet, хоть Wi-fi или даже скоромное видео.

Сможете добавить в чип Eternet/USB/SATA/SD замечательно.
Но черт побери дайте процессор с которым можно работать который можно добвешивать чем надо!
Лучше расскажите нам как Вы «гибкой методологией» а не водопадом внедряли для примера новые бизнес фичи от VISA, а еще лучше требования или отчеты ЦБ РФ? Как вам удалось внедрить ЕСИА и ЕБС?
Наверное написали письмо в ЦБ что мол сроки не важны, и что регламенты не нужны?
Попытка повторить MSX/MSX2
А вот с этого места поподробней пожалуйста. "… электроны начинают притягиваться друг к другу за счет фотонов...". Может не стоит постить такие статьи если их не получается качественно перевести?
Извините мой русский, но есть хорошевшее русское слово Стек (читается стэк).
Давайте будем конкретными:
1 «Купив новый ноутбук...». Какой ноут вы купили?
2 «моя любимая Ubuntu » Какая версия Ubuntu?
3 Вы хранили оригинальный диск от ноута с виндовозом и поставили Linux на новый диск или перенесли диск с Linux со старого ноута?
Есть только один совет из двух частей-изучайте чужой опыт!
— Изучайте опыт выживших старичков потому то они выжили
— Изучайте опыт умерших старичков потому что они умерли.
Почему Google, а не Yahoo или AltaVista?
Почему TCP/IP, а не IPX или X25?
Почему MS-DOS, а не DR-DOS?
Почему А, а не Б?
Когда молодняк говорит что он знает «крутую технологию А» и хочет за это получит 100K$, вопрос всегда один – а какие еще технологии есть и/или умерли вокруг этой технологии? Что вы видите «с вершина технологии А»? А действительно ли вы на вершине, раз ни чего не видите и не можете рассказать про окружение? Может вы в самом темном подвале, а не на вершине башни?
Когда идет самый такой, самый сякой, самый о-го-го, в итоге оказывается что он САМЫЙ не нужный.
Ну вот Go добрался до энтерпрайза. Когда nj казавшаяся гениальной конструкцией
varResult, errCode = func()
разбилась о реальности разработки – что надо не только обрабатывать varResult на месте, но и еще обрабатывать на месте errCode. Ход гениален, но вот алгоритм то у нас «однопоточный» (имеется ввиду листинг программы). Но люди помнящие Basic очень хорошо помнят что значит обрабатывать ошибку в месте ее возникновения.
А потом придет еще пушистый зверек когда какой ни будь умник захочет сделать errCode не целочисленным. И выяснится что динамическое типизирование ой как сложно поддерживать в промышленных объемах. И понесётся и понесется…
+ Попрактиковались в написании своих костылей за счет заказчика
Не угадали. Заказчику пофигу есть у нас гит или нет, это совершенно не важно. Ему важно работает или нет ПО в установленные сроки с установленным функционалом. И мой заказчик сидит этажом выше.

+ Ощущаете за собой право осуждать современное ПО в котором не разбираетесь (но, скорее всего, только внутри команды)
Угадали. У нас разработка не ради разработки, а ради конечного продукта. Если у какого то разработчика есть время лазить по сырцам и предлагать изменить код в местах которые ему не делегированы для разработки — это проблема его руководителя что не может эффективно использовать трудовой ресурс. А современное ПО это что?

— Нет возможности правки одного файла одновременно несколькими разработчиками
Серьезно? У нас относительно спроектированная и декомпозированная структура ПО. Я не говорю что каждая константа или функция в отдельном файле, но каждый класс или хранимая процедура в отдельном. Первый признак проблем в архитектуре и в частности архитектуре сырцов потребность одновременно исправить одну функцию или одну строку кода двум разработчиками.

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

— Нет нормальной истории изменений, что затрудняет поиск причины правок
Это реально смешно Вы знаете сколько раз в день разработчик или его среда разработки фиксирует через save? И как он меняет файл между этими сейвами? А я знаю и поверьте в файловой системе все ходы записаны и восстановить версию файла нет проблем. Вы сталкивались с тем что у вас все работало между 11 и12 часами и вы это поняли только в 16:00 и вопрос как откатится в гите реально решен? Вы пушите в гит после каждого изменения файла или только перед сборкой или только когда сочтете нужным?

— Вероятнее всего откат правок конкретных изменений одного разработчика невозможен
См. предыдущий комментарий и ваш вопрос не то что не вопрос, а сама суть системы.

— Введение в проект новых разработчиков затруднено. Люди, работавшие с нормальными VCS крутят пальцем у виска.
И опять не угадали! Ввиду того что используется самое простое и элементарное для хранения сырцов –файловая система. То уровень входа не то что нулевой, а как тест на профпригодность. Вы не можете сохранять проект в одни и те же файлы? – Если нет то вы нам просто не подходите как разработчик.

=Зачем вам отдельный специалист для слияния кода из веток тоже остается под вопросом, разобраться с Git-ом даже для джуна вопрос пары дней. А для разработчиков с 25-ти летним опытом тем более.
К сожалению разбирались и разобрались. Не подходи гит как система управления сырцам и их версиями. Для «базара» может быть да, но администрировать базар у нас нет задачи.

=Это у вас просто когда-то понавыдумывали своих велосипедов, а теперь вы боитесь тронуть то что и так работает. В принципе имеет право на жизнь, но со временем рынок вас сожрет — старые программисты уйдут на пенсию, а новые к вам не пойдут, потому что у вас даже гита нет.
Спишемся через 25 лет ;)

У меня нет не то что задачи, а даже желания наставить кого то на истинный путь и уж тем более научить кого то. Просто глядя на «современную разработку» диву даёшься как такое можно сделать, зачем вы все усложняете!
Ввиду того «сообщество» не переносит критики, писать могу не чаще чем раз в сутки так что ответ обобщенный.
Просто обычный банк. За 25 лет разработки не просто не возникла потребность в каких то внешних СКВ. «Репозиторий» просто файловая шара (сейчас чуть более 500 Мб исходников в 12 тыс. файлах и 300 каталогах ), с правами на файловую систему через глобальную службу аутентификации, когда была NetWare сейчас LDAP. Работа полностью автономна не требуется не грамма интернета. В репозитории разработчикам доступно обычно 2 максимум 3 версии (версии есть полное дерево в файловой системе). Первая продакшен версия, вторая может быть которая используется для пользовательского тестирования, последняя (3-ая) для разработки. Т.к. у нас изначально есть техническое задние мы можем и открывать файлы на изменение только тому кому надо. Регрессионное тестирование делается на девелперсокй версии и опять же в режиме реадонли для тестеров. Версионность поддерживается файловой системой (это отдельный том файлового хранилища). В виду использования базовых вещей — файлового доступа, работает в любых условиях хоть vim, хот ed или какой то кодогенератор. Конечно поверху наворочено куча скриптов для контроля, что нет парных доступов или не дали лишние доступы. Но мы точно знаем прежде чем что либо исправлять или добавлять мы знаем что будем делать, как писать, у нас всегда есть техзадание. Были конечно проблемы когда надо было вставить срочно ставить хотфикс на лету и он рушил девелоперскую версию, но извините у нас среда 25х8 и рабочий бизнес важнее чем текущая разработка/доработка.
И соберу еще минусов от «новомодных», у нас даже нет ни scrum ни agile. И таких новомодных просим держать свое мнение при себе и чаще всего искать другое место работы. У нас простой водопад или водопад с параллельными процессами. Нам для разработки нужно соблюсти 2 момента: сроки разработки, и соответствие ТЗ.
Попытки ввести agile и оно же с ними разбились об элементарные вопросы «Вы серьёзно будете создавать и сортировать свой бэклог, а не делать то что уже написано в ТЗ?», «Или вы серьезно считаете что информационная система без инструкции и документации это допустимо?», «Вы хотите нанять еще специалиста который будет разбираться со слиянием кода из веток?».
Так что вот так и у нас не контора по разработке ПО, а организация занимающаяся предоставлением финансовых услуг.
«Не знаю, на каком языке программирования вы пишете, но уверен, что используете Гит при разработке». Знали бы как вы заблуждаетесь!
Гит хорош когда у Вас в разработке «базар» — когда один и тоже кусок кода могут править несколько человек, но промышленная или внутренняя разработка она не такая. В ней все четко разделено. Когда у вас есть сроки, требования и требования к качеству кода вам некогда заниматься слиянием/разлиянием веток, разбором конфликтов –вы просто блокируете код/интерфейсы и пишете. Изменилось поведение или изменились интерфейсы – новая значительная версия.
Супер и очень правильно! Но возникает вопрос на сколько найм разработчиков соответствует этому? Или разработчики не инженеры?
Если по твоей магнитной полосе с чиповой карты для примера прилетит транзакция из Индии то по идее ты не можешь ее отклонить. EMV shift liability еще не обще мировое требование.
О чем это тест?
О том что угадали вы решение каких то дизайнеров или нет!?!? А кто вам сказа что это решение правильное и положительное повлияло на рейтинги и качество сайта? Что пользователи довольны?
Учитывая цифры голосования в опросе можно с большой долей вероятности говорить о том что «там» не угадали «самое правильное решение» и вообще не ясно действительно ли «там» выбирали из этого списка вариантов.
Да и вообще необходим запомнить что «нет серебряной пули в дизайне!». Если вы действительно качественная контра то вы будет поддерживать несколько версий для разных групп клиентов. Или дать им возможность настроить вью под себя.
А потом приходит ФСБ и говорит что ключи шифрования бакабов или чего угодно не являются тайной и вы их обязаны предоставить.
Все совсем чуть-чуть не так.
РКН обратился в FB с этим запросом по простой причине. Для РКН нужен формальный повод заявить «FB работает с нами, проблем нет». Т.е. если РКН обратится с требованием «а ну все данные российских пользователей на сервера в Россию» то их отправят в путешествие из которого обычно не возвращаются. А сам вопрос о переносе данных в Россию будут замылевать и тянуть.
Сейчас для МЦ подобные действия на встречу российским органам будут схожи со «шпионажем в пользу России». И если на весах как минимум падение капитализации компании и потеря места президента FB или «блокировка» FB в России. Да он выберет второе, т.к. в этом случаи он получит еще и профит в виде «видите какой я принципиальный борец за демократию и свободу слова».
Очень хочется сказать гадость и я ее скажу.
Когда же ваши маркетологи поймут что надо не придумывать продукт, а потом придумывать для чего и кому его впарить. А сперва поинтересоваться что действительно нужно потребителям!
Задайте вопросы потребителям, сделайте формы для голосования на сайте по конфигурациям и самое главное не бойтесь что по результатам этих голосований выяснится что 90% вашей продукции ни кому не нужное говно. Гоните к черту ваших маркетологов и общайтесь с клиентами напрямик!

Information

Rating
Does not participate
Location
Ямайка
Date of birth
Registered
Activity