Скриншоты какой системы представлены в сообщении выше?
Anonymous Poll
23%
Прототип Windows 2000
6%
Прототип Windows XP
8%
Отмененная Windows 2001
14%
Планируемая пользовательская ОС на базе Windows 2000
14%
Прототип Windows Me
19%
Такой системы не существовало, это фейк
15%
Ничего не понятно, но очень интересно
Взлет и падение Novell NetWare
Давным-давно осенью 1981 года группа вчерашних выпускников Дэйл Найбауэр, Дрю Мэйджер, Кайл Пауэл и Марк Хёрст основали небольшую компанию SuperSet Software, которая занималась внедрением персональных компьютеров и начала писать софт для файлового сервера на базе CP/M с процессором Motorola 68000.
Именно такие сервера продавала в их городке небольшая, основанная в 1979 году фирма Novell Джорджа Кановы.
Довольно скоро разработчики осознали, что перспективы у операционной системы CP/M нет, поэтому они решили разрабатывать собственную сетевую операционную систему.
Джордж Канова тем временем активно искал инвестиции и в 1983 году компания была преобразована в Novell, Inc., а её главой стал инвестор Рей Нурда.
Таким образом все герои нашего сегодняшнего повествования в итоге собрались под одной крышей и в этом же году выпустили операционную систему NetWare 68 для Motorola 68000, а в 1985 NetWare 86 для Intel 8086.
Для своего времени система оказалась революционной, все что вам нужно было для организации собственной сети – это купить сервер с Novell NetWare и установить на ПК программу-клиент, которая позволяла организовать плоскую сеть с общим доступом к файлам и папкам, что для 1983 года было технологическим прорывом.
Система использовала сетевой стек IPX/SPX разработки Novell, а для доступа к файлам, папкам, печати, синхронизации часов и т.д. использовался протокол NetWare Core Protocol (NCP).
При этом сетевые папки подключались на клиентские ПК как сетевые диски, но работа с ними благодаря протоколу NCP шла не на уровне блочных устройств, а именно на уровне файлов, что позволяло получать выдающуюся по тем временам производительность.
В дальнейшем в Novell отказались от поддержки Motorola 68000 и вообще выпуска собственного оборудования, а сосредоточили все усилия на сетевой операционной системе.
В 1986 году после выпуска Intel 80286 появилась NetWare 286, а в 1989 NetWare 386 для процессора Intel 80386, в дальнейшем, на фоне выпуска Windows 3.0 системы были переименованы в NetWare 2.х и NetWare 3.x соответственно.
Реальных конкурентов в то время у Netware не было, система отличалась простотой, модульностью, скоростью работы и стабильностью, один раз настроенный сервер Netware мог работать годами без вмешательства администратора.
Также Novell обеспечивала серьезное преимущество по производительности, иногда даже в соотношении от 5:1 до 10:1 с основными своими конкурентами.
Лебединой песней стал выпуск NetWare 4.x в которой впервые была представлена собственная служба каталогов NDS (домен) и произошло это в 1993 году. Началась эпоха доминирования NetWare в локальных сетях, а руководство начало почивать на лаврах, что не довело до добра.
Первый звоночек прозвучал в 1994 году с выходом Windows NT 3.5, Novell желая усложнить жизнь основному конкуренту начала затягивать выпуск клиента Novell для Windows NT в результате чего Microsoft написала собственный клиент, который оказался настолько удачным, что продолжал широко использоваться даже после выхода официального клиента.
Но время уже было упущено и было упущено не только оно, внедрение в Windows стека протоколов TCP/IP делало его универсальным клиентом для любых сетей и только увеличивала его популярность.
Разработка модуля NetWare/IP не спасло положение, как и выпуск Netware 5.x с встроенной поддержкой стека TCP/IP. Еще одной проблемой стало то, что Netware предоставлял только файловые службы и не был способен работать в качестве сервера приложений.
А былые преимущества стремительно нивелировались подросшей мощностью железа. Сказалось также и наплевательское отношение к разработчикам под Netware, что серьезно затруднило создание сторонних приложений.
Окончательную точку в истории поставил Windows NT 4.0 Terminal Server, который вышел в 1998 году и позволял сделать то, чего не умел Novell – терминальный сервер. С этого момента популярность Netware неуклонно покатилась вниз.
Последними версиями стали 6.0 (2001) и 6.5 (2003), но они уже ничего не могли изменить.
Давным-давно осенью 1981 года группа вчерашних выпускников Дэйл Найбауэр, Дрю Мэйджер, Кайл Пауэл и Марк Хёрст основали небольшую компанию SuperSet Software, которая занималась внедрением персональных компьютеров и начала писать софт для файлового сервера на базе CP/M с процессором Motorola 68000.
Именно такие сервера продавала в их городке небольшая, основанная в 1979 году фирма Novell Джорджа Кановы.
Довольно скоро разработчики осознали, что перспективы у операционной системы CP/M нет, поэтому они решили разрабатывать собственную сетевую операционную систему.
Джордж Канова тем временем активно искал инвестиции и в 1983 году компания была преобразована в Novell, Inc., а её главой стал инвестор Рей Нурда.
Таким образом все герои нашего сегодняшнего повествования в итоге собрались под одной крышей и в этом же году выпустили операционную систему NetWare 68 для Motorola 68000, а в 1985 NetWare 86 для Intel 8086.
Для своего времени система оказалась революционной, все что вам нужно было для организации собственной сети – это купить сервер с Novell NetWare и установить на ПК программу-клиент, которая позволяла организовать плоскую сеть с общим доступом к файлам и папкам, что для 1983 года было технологическим прорывом.
Система использовала сетевой стек IPX/SPX разработки Novell, а для доступа к файлам, папкам, печати, синхронизации часов и т.д. использовался протокол NetWare Core Protocol (NCP).
При этом сетевые папки подключались на клиентские ПК как сетевые диски, но работа с ними благодаря протоколу NCP шла не на уровне блочных устройств, а именно на уровне файлов, что позволяло получать выдающуюся по тем временам производительность.
В дальнейшем в Novell отказались от поддержки Motorola 68000 и вообще выпуска собственного оборудования, а сосредоточили все усилия на сетевой операционной системе.
В 1986 году после выпуска Intel 80286 появилась NetWare 286, а в 1989 NetWare 386 для процессора Intel 80386, в дальнейшем, на фоне выпуска Windows 3.0 системы были переименованы в NetWare 2.х и NetWare 3.x соответственно.
Реальных конкурентов в то время у Netware не было, система отличалась простотой, модульностью, скоростью работы и стабильностью, один раз настроенный сервер Netware мог работать годами без вмешательства администратора.
Также Novell обеспечивала серьезное преимущество по производительности, иногда даже в соотношении от 5:1 до 10:1 с основными своими конкурентами.
Лебединой песней стал выпуск NetWare 4.x в которой впервые была представлена собственная служба каталогов NDS (домен) и произошло это в 1993 году. Началась эпоха доминирования NetWare в локальных сетях, а руководство начало почивать на лаврах, что не довело до добра.
Первый звоночек прозвучал в 1994 году с выходом Windows NT 3.5, Novell желая усложнить жизнь основному конкуренту начала затягивать выпуск клиента Novell для Windows NT в результате чего Microsoft написала собственный клиент, который оказался настолько удачным, что продолжал широко использоваться даже после выхода официального клиента.
Но время уже было упущено и было упущено не только оно, внедрение в Windows стека протоколов TCP/IP делало его универсальным клиентом для любых сетей и только увеличивала его популярность.
Разработка модуля NetWare/IP не спасло положение, как и выпуск Netware 5.x с встроенной поддержкой стека TCP/IP. Еще одной проблемой стало то, что Netware предоставлял только файловые службы и не был способен работать в качестве сервера приложений.
А былые преимущества стремительно нивелировались подросшей мощностью железа. Сказалось также и наплевательское отношение к разработчикам под Netware, что серьезно затруднило создание сторонних приложений.
Окончательную точку в истории поставил Windows NT 4.0 Terminal Server, который вышел в 1998 году и позволял сделать то, чего не умел Novell – терминальный сервер. С этого момента популярность Netware неуклонно покатилась вниз.
Последними версиями стали 6.0 (2001) и 6.5 (2003), но они уже ничего не могли изменить.
👍31❤5🥱3😱2🤔1
История создания и развития IBM PC
На рынок персональных компьютеров руководство IBM обратило внимание в начале 80-го года, когда он был плотно занять такими признанными игроками Apple, Atari, Tandy и Commodore. Они выпускали 8-битные компьютеры для любителей писать программы на языке Бейсик.
Основным разработчиком Бейсик-продуктов была небольшая компания Microsoft, которую возглавлял недоучившийся студент Гарварда Билл Гейтс.
Бизнес по производству ПК в то время не представлялся руководству IBM имеющим настоящее, не говоря уже о будущем, но тем не менее компания считала нужным свое присутствие на этом рынке.
Команде разработчиков были поставлены самые жесткие сроки – менее года, а провал проекта грозил серьезными оргвыводами, поэтому были приняты многие решения, о которых компания впоследствии сильно пожалела.
Сжатые сроки означали, что система должна была строиться на основе уже существующих технологий и в качестве процессора был выбран 16-разрядный процессор 8088 от компании Intel.
Руководитель проекта, Дональд Эстридж, настоял на том, чтобы сделать архитектуру будущего IBM PC открытой, это позволяло воспользоваться силами сторонних производителей для выпуска периферии для нового компьютера, чтобы сразу обеспечить ее широкий ассортимент.
Вторая роковая ошибка была в том, что IBM позволило Билу Гейтсу самостоятельно продавать новую операционную систему под именем MS-DOS. Но тут деваться было некуда.
Первоначально Эстридж хотел использовать уже существующую CP/M, но руководитель Digital Research Гари Килдалл отказался подписать соглашение о неразглашении и проект зашел в тупик. Также версию CP/M для 16-разрядных компьютеров еще только предстояло разработать.
Ограничение по времени было очень жестким и тогда Гейтс и Эстридж пошли на авантюрное решение.
У Пола Аллена был знакомый Тим Паттерсон, который в начале 80-года начал писать CP/M совместимую систему для Intel 8086, назвав ее QDOS
Гейтсу осталось только перекупить QDOS за скромные 50 тыс. долларов и силами того же Тима довести до ума.
Это решение, несмотря не все его недостатки, фактически созданное в невероятной спешке на коленках стало для Эстриджа палочкой-выручалочкой, позволившей получить в срок операционную систему для будущего компьютера.
IBM PC (IBM 5150, процессор Intel 8088) был представлен публике 12 августа 1981 года и неожиданно стал пользоваться огромным успехом, если изначально компания планировала продать 250 тыс. ПК в течении пяти лет, то очень скоро она начала продавать такое же количество ПК ежемесячно.
Эстридж, как грамотный инженер, получил то, что хотел – ПК практически сразу стал поддержан большим количеством периферии, но компания получила еще один неприятный момент – клоны.
Действительно, любой мог купить процессор от Intel и операционную систему от Microsoft и уже в 1982 некая компания-выскочка Compaq представила клон IBM PC, а к 1984 году на рынке IBM-совместимых ПК конкурировали как новички, так и известные компании.
Но IBM сохраняло за собой лидерство, выпустив в 1983 году IBM PC XT, в состав которого впервые входил жесткий диск, а в 1984 PC AT на базе процессора 286.
Лидерство ускользнуло в 1986, когда Compaq первым представил 32-разрядный компьютер на базе процессора 386. Несмотря на то, что технически это клон AT, все-таки это был самый быстрый и современный ПК и выпустила его не IBM.
Тем временем компания готовила «ответный удар» в виде нового поколения ПК PS/2, для которого учла ошибки прошлого и которое базировалась на закрытой, обложенной патентами архитектуре.
Но несмотря на мощную рекламную компанию PS/2 провалился и термин IBM-совместимые компьютеры стал просто неуместен и все бывшие клоны IBM PC превратились просто в ПК или персональные компьютеры.
А компании IBM так и не смогла вернуть себе лидерство на рынке персональных компьютеров.
Эта история закончилась в декабре 2004 г. продажей IBM за 1,75 млрд. долл. своего подразделения ПК китайской компании Lenovo.
На рынок персональных компьютеров руководство IBM обратило внимание в начале 80-го года, когда он был плотно занять такими признанными игроками Apple, Atari, Tandy и Commodore. Они выпускали 8-битные компьютеры для любителей писать программы на языке Бейсик.
Основным разработчиком Бейсик-продуктов была небольшая компания Microsoft, которую возглавлял недоучившийся студент Гарварда Билл Гейтс.
Бизнес по производству ПК в то время не представлялся руководству IBM имеющим настоящее, не говоря уже о будущем, но тем не менее компания считала нужным свое присутствие на этом рынке.
Команде разработчиков были поставлены самые жесткие сроки – менее года, а провал проекта грозил серьезными оргвыводами, поэтому были приняты многие решения, о которых компания впоследствии сильно пожалела.
Сжатые сроки означали, что система должна была строиться на основе уже существующих технологий и в качестве процессора был выбран 16-разрядный процессор 8088 от компании Intel.
Руководитель проекта, Дональд Эстридж, настоял на том, чтобы сделать архитектуру будущего IBM PC открытой, это позволяло воспользоваться силами сторонних производителей для выпуска периферии для нового компьютера, чтобы сразу обеспечить ее широкий ассортимент.
Вторая роковая ошибка была в том, что IBM позволило Билу Гейтсу самостоятельно продавать новую операционную систему под именем MS-DOS. Но тут деваться было некуда.
Первоначально Эстридж хотел использовать уже существующую CP/M, но руководитель Digital Research Гари Килдалл отказался подписать соглашение о неразглашении и проект зашел в тупик. Также версию CP/M для 16-разрядных компьютеров еще только предстояло разработать.
Ограничение по времени было очень жестким и тогда Гейтс и Эстридж пошли на авантюрное решение.
У Пола Аллена был знакомый Тим Паттерсон, который в начале 80-года начал писать CP/M совместимую систему для Intel 8086, назвав ее QDOS
Гейтсу осталось только перекупить QDOS за скромные 50 тыс. долларов и силами того же Тима довести до ума.
Это решение, несмотря не все его недостатки, фактически созданное в невероятной спешке на коленках стало для Эстриджа палочкой-выручалочкой, позволившей получить в срок операционную систему для будущего компьютера.
IBM PC (IBM 5150, процессор Intel 8088) был представлен публике 12 августа 1981 года и неожиданно стал пользоваться огромным успехом, если изначально компания планировала продать 250 тыс. ПК в течении пяти лет, то очень скоро она начала продавать такое же количество ПК ежемесячно.
Эстридж, как грамотный инженер, получил то, что хотел – ПК практически сразу стал поддержан большим количеством периферии, но компания получила еще один неприятный момент – клоны.
Действительно, любой мог купить процессор от Intel и операционную систему от Microsoft и уже в 1982 некая компания-выскочка Compaq представила клон IBM PC, а к 1984 году на рынке IBM-совместимых ПК конкурировали как новички, так и известные компании.
Но IBM сохраняло за собой лидерство, выпустив в 1983 году IBM PC XT, в состав которого впервые входил жесткий диск, а в 1984 PC AT на базе процессора 286.
Лидерство ускользнуло в 1986, когда Compaq первым представил 32-разрядный компьютер на базе процессора 386. Несмотря на то, что технически это клон AT, все-таки это был самый быстрый и современный ПК и выпустила его не IBM.
Тем временем компания готовила «ответный удар» в виде нового поколения ПК PS/2, для которого учла ошибки прошлого и которое базировалась на закрытой, обложенной патентами архитектуре.
Но несмотря на мощную рекламную компанию PS/2 провалился и термин IBM-совместимые компьютеры стал просто неуместен и все бывшие клоны IBM PC превратились просто в ПК или персональные компьютеры.
А компании IBM так и не смогла вернуть себе лидерство на рынке персональных компьютеров.
Эта история закончилась в декабре 2004 г. продажей IBM за 1,75 млрд. долл. своего подразделения ПК китайской компании Lenovo.
👍19🥱4❤1
Система отслеживания состояния соединений conntrack, часть 1
Conntrack – важная часть сетевого стека Linux ответственная за определение сетевых соединений и связывания с ними конкретных пакетов. На основе состояния соединения строится логика работы брандмауэра netfilter, а также высокоуровневых интерфейсов к нему, таких как iptables и nftables.
Несмотря на видимую простоту с работой conntrack связано множество заблуждений и в этой заметке мы постараемся разобрать некоторые из них.
Прежде всего соединения conntrack, равно как и их состояния существуют сугубо в пределах брандмауэра и нигде более. Кроме того, это исключительно Linux-технология и в среде других ОС она не применима.
В рамках пользовательского пространства доступно четыре состояния, это всем известные NEW, ESTABLISHED, RELATED и INVALID.
Трассировка соединений происходит в цепочке PREROUTING или OUTPUT, если пакет был порожден локальным процессом. Первый пакет соединения получает статус NEW.
И вот здесь есть один важный момент, как conntrack определяет, что этот пакет первый. Например, для TCP мы можем ориентироваться на флаг SYN, но как быть с UDP, где каждый пакет, по сути, первый и последний?
Тут все просто, анализируется адрес и порт источника, адрес и порт приемника и если такой записи в таблице трассировщика нет, то пакет становится первый и ему присваивается состояние NEW.
Таким образом если в брандмауэр придет TCP пакет уже установленного соединения (без SYN), то conntrack все равно повесит ему состояние NEW и отправит дальше по цепочкам.
Это позволяет подхватывать уже установленные TCP-соединения если таблица трассировщика была утеряна (скажем мы перезагрузили роутер).
Что будет с пакетом NEW дальше? Он пойдет по цепочкам брандмауэра и будет либо пропущен, либо отброшен.
С отброшен все понятно, соединение было отвергнуто с нашей стороны и все повторные попытки соединения снова получат состояние NEW.
А вот если пакет был пропущен, то ему присваивается состояние ESTABLISHED? А вот и нет. Для перехода соединения в состояние ESTABLISHED требуется, чтобы через conntrack прошел ответ на этот пакет.
И только при наличии ответа узла состояние соединения перейдет в установленное – ESTABLISHED. Причем данное состояние устанавливается как для TCP, так и для UDP, хотя последний в принципе не подразумевает установление соединений.
Но, напоминаем, все эти соединения живут только внутри брандмауэра Linux и никак не отражаются в самих пакетах.
Для времени жизни UDP соединения используется таймаут, если за указанное в нем время через соединение не прошел ни один пакет – оно считается закрытым. Если пакет прошел – то таймаут сбрасывается и начинается новый отсчет.
С TCP все немного сложнее, при нормальном завершении соединения после получения FIN соединение в брандмауэре переходит в состояние TIME OUT (буферное время) и еще в течении некоторого времени считается ESTABLISHED. Это сделано для того, чтобы через брандмауэр могли пройти пакеты «застрявшие» где-то там по дороге.
Если соединение было закрыто по RST, то оно сразу переходит в состояние закрытого без выделения буферного времени.
При аварийном завершении TCP-соединения его состояние в conntrack будет ESTABLISHED до истечения тайм-аута.
Еще интереснее с ICMP, может ли ICMP быть ESTABLISHED? Может, и даже становится. Почему? Потому что многие типы ICMP подразумевают ответ на запрос. Поэтому пришедший ICMP пакет получит состояние NEW, а ответ на него переведет соединение в состояние ESTABLISHED.
Однако conntrack понимает, что дальнейшей передачи данных такое «соединение» не подразумевает и после прохождения ответного пакета через netfilter запись о соединении из таблицы трассировщика удаляется.
Conntrack – важная часть сетевого стека Linux ответственная за определение сетевых соединений и связывания с ними конкретных пакетов. На основе состояния соединения строится логика работы брандмауэра netfilter, а также высокоуровневых интерфейсов к нему, таких как iptables и nftables.
Несмотря на видимую простоту с работой conntrack связано множество заблуждений и в этой заметке мы постараемся разобрать некоторые из них.
Прежде всего соединения conntrack, равно как и их состояния существуют сугубо в пределах брандмауэра и нигде более. Кроме того, это исключительно Linux-технология и в среде других ОС она не применима.
В рамках пользовательского пространства доступно четыре состояния, это всем известные NEW, ESTABLISHED, RELATED и INVALID.
Трассировка соединений происходит в цепочке PREROUTING или OUTPUT, если пакет был порожден локальным процессом. Первый пакет соединения получает статус NEW.
И вот здесь есть один важный момент, как conntrack определяет, что этот пакет первый. Например, для TCP мы можем ориентироваться на флаг SYN, но как быть с UDP, где каждый пакет, по сути, первый и последний?
Тут все просто, анализируется адрес и порт источника, адрес и порт приемника и если такой записи в таблице трассировщика нет, то пакет становится первый и ему присваивается состояние NEW.
Таким образом если в брандмауэр придет TCP пакет уже установленного соединения (без SYN), то conntrack все равно повесит ему состояние NEW и отправит дальше по цепочкам.
Это позволяет подхватывать уже установленные TCP-соединения если таблица трассировщика была утеряна (скажем мы перезагрузили роутер).
Что будет с пакетом NEW дальше? Он пойдет по цепочкам брандмауэра и будет либо пропущен, либо отброшен.
С отброшен все понятно, соединение было отвергнуто с нашей стороны и все повторные попытки соединения снова получат состояние NEW.
А вот если пакет был пропущен, то ему присваивается состояние ESTABLISHED? А вот и нет. Для перехода соединения в состояние ESTABLISHED требуется, чтобы через conntrack прошел ответ на этот пакет.
И только при наличии ответа узла состояние соединения перейдет в установленное – ESTABLISHED. Причем данное состояние устанавливается как для TCP, так и для UDP, хотя последний в принципе не подразумевает установление соединений.
Но, напоминаем, все эти соединения живут только внутри брандмауэра Linux и никак не отражаются в самих пакетах.
Для времени жизни UDP соединения используется таймаут, если за указанное в нем время через соединение не прошел ни один пакет – оно считается закрытым. Если пакет прошел – то таймаут сбрасывается и начинается новый отсчет.
С TCP все немного сложнее, при нормальном завершении соединения после получения FIN соединение в брандмауэре переходит в состояние TIME OUT (буферное время) и еще в течении некоторого времени считается ESTABLISHED. Это сделано для того, чтобы через брандмауэр могли пройти пакеты «застрявшие» где-то там по дороге.
Если соединение было закрыто по RST, то оно сразу переходит в состояние закрытого без выделения буферного времени.
При аварийном завершении TCP-соединения его состояние в conntrack будет ESTABLISHED до истечения тайм-аута.
Еще интереснее с ICMP, может ли ICMP быть ESTABLISHED? Может, и даже становится. Почему? Потому что многие типы ICMP подразумевают ответ на запрос. Поэтому пришедший ICMP пакет получит состояние NEW, а ответ на него переведет соединение в состояние ESTABLISHED.
Однако conntrack понимает, что дальнейшей передачи данных такое «соединение» не подразумевает и после прохождения ответного пакета через netfilter запись о соединении из таблицы трассировщика удаляется.
10👍19🔥4❤1
Электроника ВМ-12
Данный советский видеомагнитофон не пользовался большой популярностью по прямому назначению, особенно когда в начале 90-х в страну хлынула волна зарубежной техники.
Но, в конце 90-х и начале нулевых эти видеомагнитофоны пользовались ажиотажным спросом. Их искали по комиссионкам, по объявлениям в газетах, сами давали такие объявления.
Зачем? И почему? Какие секреты хранил советский видик?
Данный советский видеомагнитофон не пользовался большой популярностью по прямому назначению, особенно когда в начале 90-х в страну хлынула волна зарубежной техники.
Но, в конце 90-х и начале нулевых эти видеомагнитофоны пользовались ажиотажным спросом. Их искали по комиссионкам, по объявлениям в газетах, сами давали такие объявления.
Зачем? И почему? Какие секреты хранил советский видик?
🔥14🥱3👍1
Электроника ВМ-12 – как много в этом слове…
Конец 90-х и начало нулевых были не простыми в экономическом плане, только – только страна отошла от дефолта 98-го, и проблема добычи средств насущных стояла остро, особенно для студентов и молодых специалистов.
Ну а где студенту взять денег? Бегали по домам, переустанавливали Windows, что-то загружали-разгружали и вообще крутились как могли.
Отдельной статьей дохода была сдача лома радиодеталей, в частности конденсаторов КМ, которые содержали палладий и скупались тогда по цене 1$ за грамм.
Поиск КМ в те годы стал одним из «национальных видов спорта» для всех, кто был в теме, ну а нам, студентам-электронщикам мимо пройти было никак.
Сначала под дерибан пошли все свои радиолюбительские запасы, затем наличествовавшая в доме электроника. Выпаять нужный конденсатор и заменить аналогом труда не представляло.
Также в дело пошли барахолки, которые были на рынках каждого города и продавалось там все подряд, включая радиодетали россыпью, платы, старую электронику.
Отдельная статья – это вынос с производства, причем как новых деталей, так и выдранных из оборудования, но нас это не касались, мы работали преимущественно в правовом поле.
Постепенно сложилась некая «табель о рангах» советской электроники откуда можно было достать такие конденсаторы. На его вершине, с огромным отрывом от остальных стоял советский видеомагнитофон Электроника ВМ-12.
В те годы он как видеомагнитофон был не нужен абсолютно никому и купить его в хорошем состоянии можно было за 500 – 800 руб. Если пересчитать на доллары, то выходило 18-30$ или такой же эквивалент в конденсаторах.
А накусать из него можно было спокойно грамм сто, а то и более. В моей практике максимум был 135 грамм, но сотка всегда накусывалась спокойно, ну или очень близко к ней.
Что такое 100$ в те времена? Это 2700 руб. или месячная зарплата начинающего специалиста. Я очень скоро пошел на свою первую работу с окладом в 2500 руб., на руки выходило со всеми надбавками примерно 2800 руб.
А когда я через два года ушел в компьютерную фирму на 4000 руб. то все считали, что мне хорошо повезло и за такое место надо держаться.
А тут вы получали чистыми (за вычетом затрат на покупку магнитофона) 2000 руб., за полчаса несложной работы кусачками.
Перепаивать конденсаторы в ВМ-12 смысла не было, очень много работы, а выхлоп копеечный. Хотя и этим занимались, когда цены на магнитофоны стали расти.
Уже через некоторое время, когда эта информация широко разошлась в народ, цены на ВМ-12 резко выросли, до 1000 – 1500 руб. Но все равно это оставалось выгодным, так как на выхлопе получалось практически еще столько сверху. Да, условная 1000 руб. – это куда хуже 2000 руб., но и она на дороге не валялась, а тут просто легкие деньги.
Доходило до того, что тебя могли тормознуть местные пацаны на районе и спросить, мол ты в КМ-ках соображаешь? Оказывается, они откопали где-то ВМ-12, но понятия не имели что оттуда выкусывать и просили помочь за долю малую. Обычно за 10-15 грамм. Иногда побольше, но в этом случае еще просили сходить с ними на сдачу, чтобы барыга их не обул как лохов (а такие случаи были).
Поэтому очень скоро ВМ-12 стал настоящим дефицитом, а при покупке его обязательно надо было открыть и убедиться, что в нем действительно стоят искомые конденсаторы КМ, так как нарваться на перепаянный магнитофон стало проще простого. Иногда на ценниках в комиссионках так и писали – КМ нет!!!
Что касается самих денег, то покупательная способность рубля тоже была иной, по причине студенческого возраста хорошо помню я в те годы только цены на пиво. Так средний пивас стоил тогда 3 – 3,5 руб. за бутылку, сейчас такое пиво в среднем 60 руб., т.е. разница примерно в 18 раз.
Посему в нынешних ценах выхлоп с одного ВМ-12 составлял 18 – 36 тыс. руб. (1000 – 2000 руб. теми деньгами), что очень неплохо даже по сегодняшним меркам.
Сегодня КМ вроде тоже скупают, примерно по 150 руб. грамм, таким образом ВМ-12 спокойно тянет на 15 тыс. грязными. Сумма, конечно, поскромнее, но все еще привлекательная.
Конец 90-х и начало нулевых были не простыми в экономическом плане, только – только страна отошла от дефолта 98-го, и проблема добычи средств насущных стояла остро, особенно для студентов и молодых специалистов.
Ну а где студенту взять денег? Бегали по домам, переустанавливали Windows, что-то загружали-разгружали и вообще крутились как могли.
Отдельной статьей дохода была сдача лома радиодеталей, в частности конденсаторов КМ, которые содержали палладий и скупались тогда по цене 1$ за грамм.
Поиск КМ в те годы стал одним из «национальных видов спорта» для всех, кто был в теме, ну а нам, студентам-электронщикам мимо пройти было никак.
Сначала под дерибан пошли все свои радиолюбительские запасы, затем наличествовавшая в доме электроника. Выпаять нужный конденсатор и заменить аналогом труда не представляло.
Также в дело пошли барахолки, которые были на рынках каждого города и продавалось там все подряд, включая радиодетали россыпью, платы, старую электронику.
Отдельная статья – это вынос с производства, причем как новых деталей, так и выдранных из оборудования, но нас это не касались, мы работали преимущественно в правовом поле.
Постепенно сложилась некая «табель о рангах» советской электроники откуда можно было достать такие конденсаторы. На его вершине, с огромным отрывом от остальных стоял советский видеомагнитофон Электроника ВМ-12.
В те годы он как видеомагнитофон был не нужен абсолютно никому и купить его в хорошем состоянии можно было за 500 – 800 руб. Если пересчитать на доллары, то выходило 18-30$ или такой же эквивалент в конденсаторах.
А накусать из него можно было спокойно грамм сто, а то и более. В моей практике максимум был 135 грамм, но сотка всегда накусывалась спокойно, ну или очень близко к ней.
Что такое 100$ в те времена? Это 2700 руб. или месячная зарплата начинающего специалиста. Я очень скоро пошел на свою первую работу с окладом в 2500 руб., на руки выходило со всеми надбавками примерно 2800 руб.
А когда я через два года ушел в компьютерную фирму на 4000 руб. то все считали, что мне хорошо повезло и за такое место надо держаться.
А тут вы получали чистыми (за вычетом затрат на покупку магнитофона) 2000 руб., за полчаса несложной работы кусачками.
Перепаивать конденсаторы в ВМ-12 смысла не было, очень много работы, а выхлоп копеечный. Хотя и этим занимались, когда цены на магнитофоны стали расти.
Уже через некоторое время, когда эта информация широко разошлась в народ, цены на ВМ-12 резко выросли, до 1000 – 1500 руб. Но все равно это оставалось выгодным, так как на выхлопе получалось практически еще столько сверху. Да, условная 1000 руб. – это куда хуже 2000 руб., но и она на дороге не валялась, а тут просто легкие деньги.
Доходило до того, что тебя могли тормознуть местные пацаны на районе и спросить, мол ты в КМ-ках соображаешь? Оказывается, они откопали где-то ВМ-12, но понятия не имели что оттуда выкусывать и просили помочь за долю малую. Обычно за 10-15 грамм. Иногда побольше, но в этом случае еще просили сходить с ними на сдачу, чтобы барыга их не обул как лохов (а такие случаи были).
Поэтому очень скоро ВМ-12 стал настоящим дефицитом, а при покупке его обязательно надо было открыть и убедиться, что в нем действительно стоят искомые конденсаторы КМ, так как нарваться на перепаянный магнитофон стало проще простого. Иногда на ценниках в комиссионках так и писали – КМ нет!!!
Что касается самих денег, то покупательная способность рубля тоже была иной, по причине студенческого возраста хорошо помню я в те годы только цены на пиво. Так средний пивас стоил тогда 3 – 3,5 руб. за бутылку, сейчас такое пиво в среднем 60 руб., т.е. разница примерно в 18 раз.
Посему в нынешних ценах выхлоп с одного ВМ-12 составлял 18 – 36 тыс. руб. (1000 – 2000 руб. теми деньгами), что очень неплохо даже по сегодняшним меркам.
Сегодня КМ вроде тоже скупают, примерно по 150 руб. грамм, таким образом ВМ-12 спокойно тянет на 15 тыс. грязными. Сумма, конечно, поскромнее, но все еще привлекательная.
2❤10👌4👍2🥱1
С днем рождения Linux!
25 августа 1991 года в рассылке новостей группы пользователей OC MINIX появилось сообщение:
Вряд ли кто-то тогда мог подумать, что оно серьезно изменит компьютерный мир уже в течении этого десятилетия. Простой студенческий проект никому не известного финского парня…
Изначально система должна была называться Freax, но Ари Лемке, который предоставил место для проекта на своем FTP сервере назвал каталог pub/OS/Linux, которое и закрепилось в качестве названия системы.
Важной вехой в развитии системы стала кооперация с проектом GNU, который еще с 1983 года под руководством Ричарда Столлмана занимался созданием полностью открытой и свободной операционной системы.
К 1991 году у Столлмана было практически все, что нужно, кроме ядра. Собственные попытки разработать ядро Hurd не привели к успеху (причем до сих пор) и тут появилось ядро, которому как раз нужно было прикладное ПО.
Уже через год начали появляться первые дистрибутивы, так в 1992 году увидел свет Slackware Патрика Фолькердинга, а в 1993 Debian Яна Мёрдока, в 1994 появились S.U.S.E и Red Hat.
В этом же году увидело свет ядро 1.0.0 содержавшее 176 250 строчек кода, а уже в 1996 была выпущена версия 2.0, началась эпоха стремительного развития молодой системы.
В этом же году появился официальный талисман системы – пингвин Tux, его нарисовал Ларри Юинг. Слово Tux придумал Джеймз Хьюз, соединив два слова: (T)orvalds (U)ni(X).
В 1998 году Матиас Эттрих представил первый выпуск KDE, которая предлагала законченную среду рабочего стола с набором программ базировавшуюся на Qt, а годом позже Мигель де Иказа и Федерико Мен выпустили первую версию GNOME на GTK+.
Менее чем за 10 лет Linux прошел путь от небольшого студенческого проекта до полноценной ОС с графической оболочкой.
В дальнейшем система продолжила развиваться и занимать новые ниши, так уже в 2002 году увидел свет Red Hat Enterprise Linux.
Домашние пользователи тоже не остались без внимания, в 1998 году появился Mandrake Linux, позже Mandriva – один из самых дружелюбных дистрибутивов того времени.
В это же время появился дистрибутив Linux-Mandrake Russian Edition, который впоследствии занялся полностью собственной разработкой и теперь мы его знаем как ALT Linux.
А сам Mandrake/Mandriva прошел сложный путь, несколько раз менял владельца пока не превратился в ROSA Linux.
Еще одно знаковое событие произошло в 2004 году, с выходом дистрибутива Ubuntu Linux, который сделал систему ближе в прямом и переносном смысле.
В те времена широкополосный интернет был еще дорог и труднодоступен, поэтому Canonical рассылала диски с Ubuntu почтой бесплатно в любую точку земного шара.
А дальше вы и так, наверное, все знаете, размер заметки не позволяет продолжать наше повествование. Поэтому еще раз вспомним как все начиналось и поздравим Linux c днем рождения.
25 августа 1991 года в рассылке новостей группы пользователей OC MINIX появилось сообщение:
всем пользователям minix!
Я пишу (бесплатную) операционную систему (это просто хобби, ничего большого и профессионального вроде gnu) для AT 386(486). Я вожусь с этим с апреля, и она, похоже, скоро будет готова. Напишите мне, кому что нравится/не нравится в minix, поскольку моя ОС на неё похожа (кроме всего прочего, у неё — по практическим соображениям — то же физическое размещение файловой системы).
Пока что я перенёс в неё bash (1.08) и gсс (1.40), и всё вроде работает. Значит, в ближайшие месяцы у меня получится уже что-то работающее, и мне бы хотелось знать, какие функции нужны большинству. Все заявки принимаются, но выполнение не гарантируется :-)
Линус ([email protected])
PS. Она свободна от кода minix и включает мультизадачную файловую систему. Она НЕ переносима (используется переключение задач 386 и пр.) и, возможно, никогда не будет поддерживать ничего, кроме АТ-винчестеров, потому что у меня больше ничего нет :-(
Вряд ли кто-то тогда мог подумать, что оно серьезно изменит компьютерный мир уже в течении этого десятилетия. Простой студенческий проект никому не известного финского парня…
Изначально система должна была называться Freax, но Ари Лемке, который предоставил место для проекта на своем FTP сервере назвал каталог pub/OS/Linux, которое и закрепилось в качестве названия системы.
Важной вехой в развитии системы стала кооперация с проектом GNU, который еще с 1983 года под руководством Ричарда Столлмана занимался созданием полностью открытой и свободной операционной системы.
К 1991 году у Столлмана было практически все, что нужно, кроме ядра. Собственные попытки разработать ядро Hurd не привели к успеху (причем до сих пор) и тут появилось ядро, которому как раз нужно было прикладное ПО.
Уже через год начали появляться первые дистрибутивы, так в 1992 году увидел свет Slackware Патрика Фолькердинга, а в 1993 Debian Яна Мёрдока, в 1994 появились S.U.S.E и Red Hat.
В этом же году увидело свет ядро 1.0.0 содержавшее 176 250 строчек кода, а уже в 1996 была выпущена версия 2.0, началась эпоха стремительного развития молодой системы.
В этом же году появился официальный талисман системы – пингвин Tux, его нарисовал Ларри Юинг. Слово Tux придумал Джеймз Хьюз, соединив два слова: (T)orvalds (U)ni(X).
В 1998 году Матиас Эттрих представил первый выпуск KDE, которая предлагала законченную среду рабочего стола с набором программ базировавшуюся на Qt, а годом позже Мигель де Иказа и Федерико Мен выпустили первую версию GNOME на GTK+.
Менее чем за 10 лет Linux прошел путь от небольшого студенческого проекта до полноценной ОС с графической оболочкой.
В дальнейшем система продолжила развиваться и занимать новые ниши, так уже в 2002 году увидел свет Red Hat Enterprise Linux.
Домашние пользователи тоже не остались без внимания, в 1998 году появился Mandrake Linux, позже Mandriva – один из самых дружелюбных дистрибутивов того времени.
В это же время появился дистрибутив Linux-Mandrake Russian Edition, который впоследствии занялся полностью собственной разработкой и теперь мы его знаем как ALT Linux.
А сам Mandrake/Mandriva прошел сложный путь, несколько раз менял владельца пока не превратился в ROSA Linux.
Еще одно знаковое событие произошло в 2004 году, с выходом дистрибутива Ubuntu Linux, который сделал систему ближе в прямом и переносном смысле.
В те времена широкополосный интернет был еще дорог и труднодоступен, поэтому Canonical рассылала диски с Ubuntu почтой бесплатно в любую точку земного шара.
А дальше вы и так, наверное, все знаете, размер заметки не позволяет продолжать наше повествование. Поэтому еще раз вспомним как все начиналось и поздравим Linux c днем рождения.
1🔥32⚡15👏12❤9
Система отслеживания состояния соединений conntrack, часть 2
В прошлой части мы разобрали состояние NEW и ESTABLISHED, сегодня поговорим об более интересных состояниях.
Начнем с RELATED, вроде бы просто – это соединения, связанные с уже установленным соединением. Но если начинать разбираться, то вопросов становится больше, чем ответов.
Что такое связанное соединение? Это новое соединение, которое является частью уже существующего, хорошие примеры таких протоколов – это FTP, PPTP или SIP. Для них характерно наличие управляющего соединения и связанных с ним соединений для передачи данных.
Важно понимать и то, что связанное соединение может быть инициировано как изнутри, так и снаружи, при этом порт передачи данных обычно выбирается динамически, что создает проблемы с фильтрацией таких соединений.
Поэтому conntrack как-то должен понять, что это не самостоятельное соединение, иначе оно получит состояние NEW и пойдет в брандмауэр со всеми вытекающими.
Для этого он при помощи специальных модулей ядра ipconntrackNNN анализирует данные управляющих протоколов и на их основании выделяет связанные соединения.
Если новый пакет соединения, определенного как связанное попадает в брандмауэр, то ему присваивается состояние RELATED. После того, как на этот пакет будет получен ответ связанное состояние перейдет в состояние установленного – ESTABLISHED.
Таким образом RELATED – это аналог состояние NEW, но только для связанных соединений, установленных соединений с таким статусом не бывает. Все установленные соединения только ESTABLISHED.
Если у вас пакеты связанного соединения не определяются как RELATED, то это может говорить о том, что отсутствует загруженный модуль для работы с используемым протоколом.
И последнее состояние соединения – INVALID. Очень часто оно трактуется и понимается неправильно.
Скажем нам пришел TCP-пакет уже установленного соединения, но в таблице трассировщика данные о таком соединении отсутствуют. Перед нами типичный INVALID?
Вовсе нет. Если корректно указаны все необходимые поля пакета, то он получит состояние NEW. Об этом мы говорили вчера, такое поведение позволяет подхватывать уже установленные соединения без обрыва сеанса связи.
Что касается UDP, то там каждый пакет является первым, так как протокол не подразумевает установку соединения.
Тогда что такое INVALID? Это пакет, который не может быть идентифицирован, например, имеет некорректно заполненные поля или поврежден. Также сюда относятся ICMP-ответы, для которых отсутствуют соединения породившие запросы.
Напоминаем, что для типов ICMP подразумевающих ответы создается соединение с состоянием NEW и переходит в ESTABLISHED и закрывается только после получения ответа.
Поэтому если есть ответ, но нет соответствующего ему соединения, то такой пакет будет помечен как INVALID.
Также подобное состояние мы можем получить и для вполне легальных пакетов при недостатке ресурсов брандмауэра, например, закончилась свободная память или высокая нагрузка на процессор, перегрев и т.д.
Поэтому INVALID не указывает на однозначно вредоносные пакеты, а говорит о том, что conntrack не смог разобраться с идентификацией пакета и резкий всплеск получения подобного состояния может указывать именно не недостаток ресурсов, а не сетевую атаку.
В тоже время пренебрегать блокированием INVALID тоже не стоит, так как позволяет эффективно защититься от ряда атак, чаще всего через поддельные ICMP-ответы.
Но, повторимся, INVALID – это не только неправильный пакет, а любой, который conntrack по какой-либо причине не смог идентифицировать.
Непонимание этого может заставить искать вас черную кошку в темной комнате, которой там нет (сетевую атаку), вместо того, чтобы проверить режим работы оборудования.
В прошлой части мы разобрали состояние NEW и ESTABLISHED, сегодня поговорим об более интересных состояниях.
Начнем с RELATED, вроде бы просто – это соединения, связанные с уже установленным соединением. Но если начинать разбираться, то вопросов становится больше, чем ответов.
Что такое связанное соединение? Это новое соединение, которое является частью уже существующего, хорошие примеры таких протоколов – это FTP, PPTP или SIP. Для них характерно наличие управляющего соединения и связанных с ним соединений для передачи данных.
Важно понимать и то, что связанное соединение может быть инициировано как изнутри, так и снаружи, при этом порт передачи данных обычно выбирается динамически, что создает проблемы с фильтрацией таких соединений.
Поэтому conntrack как-то должен понять, что это не самостоятельное соединение, иначе оно получит состояние NEW и пойдет в брандмауэр со всеми вытекающими.
Для этого он при помощи специальных модулей ядра ipconntrackNNN анализирует данные управляющих протоколов и на их основании выделяет связанные соединения.
Если новый пакет соединения, определенного как связанное попадает в брандмауэр, то ему присваивается состояние RELATED. После того, как на этот пакет будет получен ответ связанное состояние перейдет в состояние установленного – ESTABLISHED.
Таким образом RELATED – это аналог состояние NEW, но только для связанных соединений, установленных соединений с таким статусом не бывает. Все установленные соединения только ESTABLISHED.
Если у вас пакеты связанного соединения не определяются как RELATED, то это может говорить о том, что отсутствует загруженный модуль для работы с используемым протоколом.
И последнее состояние соединения – INVALID. Очень часто оно трактуется и понимается неправильно.
Скажем нам пришел TCP-пакет уже установленного соединения, но в таблице трассировщика данные о таком соединении отсутствуют. Перед нами типичный INVALID?
Вовсе нет. Если корректно указаны все необходимые поля пакета, то он получит состояние NEW. Об этом мы говорили вчера, такое поведение позволяет подхватывать уже установленные соединения без обрыва сеанса связи.
Что касается UDP, то там каждый пакет является первым, так как протокол не подразумевает установку соединения.
Тогда что такое INVALID? Это пакет, который не может быть идентифицирован, например, имеет некорректно заполненные поля или поврежден. Также сюда относятся ICMP-ответы, для которых отсутствуют соединения породившие запросы.
Напоминаем, что для типов ICMP подразумевающих ответы создается соединение с состоянием NEW и переходит в ESTABLISHED и закрывается только после получения ответа.
Поэтому если есть ответ, но нет соответствующего ему соединения, то такой пакет будет помечен как INVALID.
Также подобное состояние мы можем получить и для вполне легальных пакетов при недостатке ресурсов брандмауэра, например, закончилась свободная память или высокая нагрузка на процессор, перегрев и т.д.
Поэтому INVALID не указывает на однозначно вредоносные пакеты, а говорит о том, что conntrack не смог разобраться с идентификацией пакета и резкий всплеск получения подобного состояния может указывать именно не недостаток ресурсов, а не сетевую атаку.
В тоже время пренебрегать блокированием INVALID тоже не стоит, так как позволяет эффективно защититься от ряда атак, чаще всего через поддельные ICMP-ответы.
Но, повторимся, INVALID – это не только неправильный пакет, а любой, который conntrack по какой-либо причине не смог идентифицировать.
Непонимание этого может заставить искать вас черную кошку в темной комнате, которой там нет (сетевую атаку), вместо того, чтобы проверить режим работы оборудования.
9👍19🔥2
Обновление касс к 1 сентября 2025 года. Что нужно знать
1 сентября давно уже стало одной из традиционных дат для внедрения различных изменений. В этом году изменения касаются касс ККМ и затрагивают практически каждое торговое предприятие.
Информации по этой теме в сети много, но не вся она, скажем мягко, соответствует действительности. Информационные ресурсы наперегонки стращают нас о необходимости обновляться, обновляться и еще раз обновляться. Но на самом деле не все так страшно.
Изменения касаются сразу нескольких, независимых друг от друга областей регулирования, поэтому исходить будем из того, чем занимается организация на самом деле. В качестве товароучетных систем будем рассматривать программы от 1С и кассы производства АТОЛ, однако и в других сочетаниях все будет плюс-минус также.
🔹 Если вы не торгуете маркированным товаром и не ведете дистанционную торговлю, то единственным изменением для вас будут новые требования к бумажному чеку. Новых печатных реквизитов там не вводится, а все нововведения касаются размеров шрифта и QR-кода. Поэтому достаточно просто обновить прошивку кассы до актуальной – 5.16.0 у АТОЛ.
🔹 Если вы работаете с маркированным товаром, то вы теперь обязаны передавать теги 1011 Часовая зона и 2040 Номер ФД кассового чека (чека коррекции). Эти чеки передаются только в отчет о реализации маркированного товара в ОФД вы их не найдете.
Казалось бы, тут неминуемо обновление, но не будем спешить, если изучить последние релизы типовых конфигураций 1С, то мы не найдем там специфичного кода, отвечающего за заполнение этих тегов, равно как интеграционная компонента остается версии 10.10.6.0.
Поэтому, если у вас все остальные требования по работе с маркированным товаром соблюдены – то можете остаться на текущем релизе, заодно избежав обновления платформы до 8.3.27.
В этом случае вам потребуется обновить прошивку и драйвер ККТ до последних версий: 5.16.0 и 10.10.7.0, после чего ККТ начнет самостоятельно передавать часовой пояс и номер ФД (который формируется ФН внутри ККТ и товароучетное по для этого не требуется).
Для контроля зайдите в личный кабинет Честного знака, скачайте чек в формате JSON и найдите в нем строки:
▫️ receiptDocumentNumber – тег 2040 Номер ФД кассового чека
▫️ timeZone – тег 1011 Часовая зона
Обычно они идут рядом по порядку. Также проконтролируйте наличие строки:
▫️ hasIncorrectCodes – тег 2107 Результаты проверки маркированных товаров
Он также передается самой ККТ и не требует дополнительных настроек.
🔹 Если вы занимаетесь торговлей в сети интернет, то для вас обязательными станут теги:
▫️ тег 1125 - Признак расчета в Интернет
▫️ тег 1187 – Адрес сайта (место расчетов)
▫️ тег 1008 – Контактные данные покупателя (телефон или e-mail)
В этом случае также обновляем прошивку и драйвер ККТ до последних версий: 5.16.0 и 10.10.7.0.
А вот с обновлением товароучетного ПО есть варианты. Мы не работаем с этой областью и точно сказать не можем что и в каком объеме формируется или не формируется в текущих версиях. Но, в общем и целом, доработки несложные и есть смысл задуматься о их реализации при помощи расширения если обновлять конфигурацию вы по каким-либо причинам не хотите.
Если дополнительно к этому вы продаете маркированный товар, то проконтролируйте наличие тегов из предыдущего пункта.
🔹 А как быть с тегами 1234 – 1238 и 1082? А никак! На текущий момент ФНС не утвердила точный порядок заполнения реквизита сведения обо всех оплатах по чеку безналичнымим (тег 1234). Поэтому, до появления приказа, можем эти теги не заполнять и не передавать.
Скажем больше, в настоящий момент попытка передачи этого тега руками приводит во многих ОФД к ошибке – неизвестный тег. Поэтому не бежим впереди паровоза, а спокойно ждем очередных сроков.
1 сентября давно уже стало одной из традиционных дат для внедрения различных изменений. В этом году изменения касаются касс ККМ и затрагивают практически каждое торговое предприятие.
Информации по этой теме в сети много, но не вся она, скажем мягко, соответствует действительности. Информационные ресурсы наперегонки стращают нас о необходимости обновляться, обновляться и еще раз обновляться. Но на самом деле не все так страшно.
Изменения касаются сразу нескольких, независимых друг от друга областей регулирования, поэтому исходить будем из того, чем занимается организация на самом деле. В качестве товароучетных систем будем рассматривать программы от 1С и кассы производства АТОЛ, однако и в других сочетаниях все будет плюс-минус также.
🔹 Если вы не торгуете маркированным товаром и не ведете дистанционную торговлю, то единственным изменением для вас будут новые требования к бумажному чеку. Новых печатных реквизитов там не вводится, а все нововведения касаются размеров шрифта и QR-кода. Поэтому достаточно просто обновить прошивку кассы до актуальной – 5.16.0 у АТОЛ.
🔹 Если вы работаете с маркированным товаром, то вы теперь обязаны передавать теги 1011 Часовая зона и 2040 Номер ФД кассового чека (чека коррекции). Эти чеки передаются только в отчет о реализации маркированного товара в ОФД вы их не найдете.
Казалось бы, тут неминуемо обновление, но не будем спешить, если изучить последние релизы типовых конфигураций 1С, то мы не найдем там специфичного кода, отвечающего за заполнение этих тегов, равно как интеграционная компонента остается версии 10.10.6.0.
Поэтому, если у вас все остальные требования по работе с маркированным товаром соблюдены – то можете остаться на текущем релизе, заодно избежав обновления платформы до 8.3.27.
В этом случае вам потребуется обновить прошивку и драйвер ККТ до последних версий: 5.16.0 и 10.10.7.0, после чего ККТ начнет самостоятельно передавать часовой пояс и номер ФД (который формируется ФН внутри ККТ и товароучетное по для этого не требуется).
Для контроля зайдите в личный кабинет Честного знака, скачайте чек в формате JSON и найдите в нем строки:
▫️ receiptDocumentNumber – тег 2040 Номер ФД кассового чека
▫️ timeZone – тег 1011 Часовая зона
Обычно они идут рядом по порядку. Также проконтролируйте наличие строки:
▫️ hasIncorrectCodes – тег 2107 Результаты проверки маркированных товаров
Он также передается самой ККТ и не требует дополнительных настроек.
🔹 Если вы занимаетесь торговлей в сети интернет, то для вас обязательными станут теги:
▫️ тег 1125 - Признак расчета в Интернет
▫️ тег 1187 – Адрес сайта (место расчетов)
▫️ тег 1008 – Контактные данные покупателя (телефон или e-mail)
В этом случае также обновляем прошивку и драйвер ККТ до последних версий: 5.16.0 и 10.10.7.0.
А вот с обновлением товароучетного ПО есть варианты. Мы не работаем с этой областью и точно сказать не можем что и в каком объеме формируется или не формируется в текущих версиях. Но, в общем и целом, доработки несложные и есть смысл задуматься о их реализации при помощи расширения если обновлять конфигурацию вы по каким-либо причинам не хотите.
Если дополнительно к этому вы продаете маркированный товар, то проконтролируйте наличие тегов из предыдущего пункта.
🔹 А как быть с тегами 1234 – 1238 и 1082? А никак! На текущий момент ФНС не утвердила точный порядок заполнения реквизита сведения обо всех оплатах по чеку безналичнымим (тег 1234). Поэтому, до появления приказа, можем эти теги не заполнять и не передавать.
Скажем больше, в настоящий момент попытка передачи этого тега руками приводит во многих ОФД к ошибке – неизвестный тег. Поэтому не бежим впереди паровоза, а спокойно ждем очередных сроков.
👍23❤5
Эталонная модель OSI
Продолжаем рассматривать модель OSI и переходим к самым интересным, верхним уровням.
🔹 Уровень 5 – сеансовый. Отвечает за установку, управление и завершение сеансов связи между приложениями. Также обеспечивает синхронизацию и управление диалогом и восстановление сеанса в случае его обрыва.
Казалось бы, достаточно просто, но отдельных протоколов сеансового уровня придется поискать днем с огнем. Обычно здесь мы можем увидеть самые различные протоколы, традиционно считаемые протоколами иных уровней.
Это прикладные RDP, SMB, SIP, RPC, канальный PPP и использующие его PPTP или L2TP. Также здесь может оказаться TLS или даже НТТP, хотя у последнего сессии «ненастоящие».
Почему так? Потому что OSI – это абстракция, а реальные протоколы – это реальные протоколы, которые работают по-своему и без оглядки на эту модель. Поэтому здесь очень многое зависит от контекста и угла, под которым мы рассматриваем данный вопрос.
В целом – если протокол занимается созданием, управлением и завершением сеансов – то этот протокол работает на сеансовом уровне OSI.
🔹 Уровень 6 – представления. Отвечает за преобразование данных, получаемых с самого верхнего уровня L7 или предоставляемых ему. Сюда относится преобразование форматов, сжатие, кодирование и шифрование, если оно не связано с защитой передаваемых данных на сетевом или транспортном уровне.
Кодируем видео с рабочего стола для конференции – это L6, звук – тоже сюда же. Сжатие на лету HTTP-содержимого – тоже к нам. И в качестве протоколов шестого уровня у нас полноценно выступают алгоритмы сжатия и медиакодеки.
А вот с шифрованием все очень не просто. Описание шестого уровня содержит оговорку, что шифрование считается работающим на L6 только если шифруются данные самого приложения и это не связано с защитой канала передачи данных.
А вот тут начинаются еще более веселые приключения. Например, приложение, прежде чем отправить некий протокольный блок данных, который, скажем содержит данные о начисленной зарплате решает его зашифровать. Это шестой уровень, однозначно.
А вот если оно отправило этот блок как есть через защищенный канал IPsec или TLS, то это ни разу ни шестой, а третий или четвертый.
И тут снова всплывает контекст и угол обзора. Вот берем, например, классический HTTPS, не касаясь его современных вариаций.
Если посмотреть под углом, что в TLS заворачивается только HTTP содержимое и ничего больше, то можно отправить TLS на шестой уровень.
А если вспомним, что перед тем, как начать заворачивать HTTP-содержимое TLS установил соединение (уровень 5 – сеансовый) и предоставляет HTTP-защищенный канал, то он становится протоколом транспортного уровня.
А если… И таких если может быть очень много. Поэтому всегда помним, что OSI – это эталонная модель, помогающая понять принцип сетевого взаимодействия, но красиво наложить на нее современные протоколы не получится, это действо сродни натягивания совы на глобус.
🔹 Уровень 7 – прикладной, он же уровень приложений. Обеспечивает взаимодействие с сетью приложений операционной системы. И позволяет им общаться через сеть «понятным» языком.
Сюда относятся все протоколы, с которыми работают конечные приложения: браузер, почтовый клиент, сетевой плеер, клиент удаленного доступа. Это HTTP, FTP, SMTP, POP3, IMAP, RDP, SMB и т.д. и т.п.
Но здесь тоже далеко не все так просто, тот же RDP или SMB кроме всего прочего еще устанавливает и управляет сеансами, занимается кодированием и преобразованием данных от приложения, т.е. равномерно распределяет свои функции между L5 -L7.
Точно также, как и на предыдущих уровнях достаточно сложно выделить протоколы именно прикладного уровня, каждый из них может быть свободно представлен на нескольких уровнях, что модель OSI не запрещает.
Что касается самой модели и ее стройности, то на этих уровнях она сильно страдает. Но это удел любой теоретической абстракции. В тоже время OSI надо знать и понимать, так как по ее образу и подобию построены многие иные модели, которые как раз используются в реальной жизни.
Продолжаем рассматривать модель OSI и переходим к самым интересным, верхним уровням.
🔹 Уровень 5 – сеансовый. Отвечает за установку, управление и завершение сеансов связи между приложениями. Также обеспечивает синхронизацию и управление диалогом и восстановление сеанса в случае его обрыва.
Казалось бы, достаточно просто, но отдельных протоколов сеансового уровня придется поискать днем с огнем. Обычно здесь мы можем увидеть самые различные протоколы, традиционно считаемые протоколами иных уровней.
Это прикладные RDP, SMB, SIP, RPC, канальный PPP и использующие его PPTP или L2TP. Также здесь может оказаться TLS или даже НТТP, хотя у последнего сессии «ненастоящие».
Почему так? Потому что OSI – это абстракция, а реальные протоколы – это реальные протоколы, которые работают по-своему и без оглядки на эту модель. Поэтому здесь очень многое зависит от контекста и угла, под которым мы рассматриваем данный вопрос.
В целом – если протокол занимается созданием, управлением и завершением сеансов – то этот протокол работает на сеансовом уровне OSI.
🔹 Уровень 6 – представления. Отвечает за преобразование данных, получаемых с самого верхнего уровня L7 или предоставляемых ему. Сюда относится преобразование форматов, сжатие, кодирование и шифрование, если оно не связано с защитой передаваемых данных на сетевом или транспортном уровне.
Кодируем видео с рабочего стола для конференции – это L6, звук – тоже сюда же. Сжатие на лету HTTP-содержимого – тоже к нам. И в качестве протоколов шестого уровня у нас полноценно выступают алгоритмы сжатия и медиакодеки.
А вот с шифрованием все очень не просто. Описание шестого уровня содержит оговорку, что шифрование считается работающим на L6 только если шифруются данные самого приложения и это не связано с защитой канала передачи данных.
А вот тут начинаются еще более веселые приключения. Например, приложение, прежде чем отправить некий протокольный блок данных, который, скажем содержит данные о начисленной зарплате решает его зашифровать. Это шестой уровень, однозначно.
А вот если оно отправило этот блок как есть через защищенный канал IPsec или TLS, то это ни разу ни шестой, а третий или четвертый.
И тут снова всплывает контекст и угол обзора. Вот берем, например, классический HTTPS, не касаясь его современных вариаций.
Если посмотреть под углом, что в TLS заворачивается только HTTP содержимое и ничего больше, то можно отправить TLS на шестой уровень.
А если вспомним, что перед тем, как начать заворачивать HTTP-содержимое TLS установил соединение (уровень 5 – сеансовый) и предоставляет HTTP-защищенный канал, то он становится протоколом транспортного уровня.
А если… И таких если может быть очень много. Поэтому всегда помним, что OSI – это эталонная модель, помогающая понять принцип сетевого взаимодействия, но красиво наложить на нее современные протоколы не получится, это действо сродни натягивания совы на глобус.
🔹 Уровень 7 – прикладной, он же уровень приложений. Обеспечивает взаимодействие с сетью приложений операционной системы. И позволяет им общаться через сеть «понятным» языком.
Сюда относятся все протоколы, с которыми работают конечные приложения: браузер, почтовый клиент, сетевой плеер, клиент удаленного доступа. Это HTTP, FTP, SMTP, POP3, IMAP, RDP, SMB и т.д. и т.п.
Но здесь тоже далеко не все так просто, тот же RDP или SMB кроме всего прочего еще устанавливает и управляет сеансами, занимается кодированием и преобразованием данных от приложения, т.е. равномерно распределяет свои функции между L5 -L7.
Точно также, как и на предыдущих уровнях достаточно сложно выделить протоколы именно прикладного уровня, каждый из них может быть свободно представлен на нескольких уровнях, что модель OSI не запрещает.
Что касается самой модели и ее стройности, то на этих уровнях она сильно страдает. Но это удел любой теоретической абстракции. В тоже время OSI надо знать и понимать, так как по ее образу и подобию построены многие иные модели, которые как раз используются в реальной жизни.
👍25🔥1🤮1
Не поле для ввода, а textarea. Чего разработчики ждут от аналитиков на самом деле
Понятные описания, точные термины, и «глупые» вопросы — стартовый набор системного аналитика, который ставит хорошие задачи на разработку.
Екатерина Петрова обсудила с инженерами из двух разных компаний их представления о роли и работе аналитиков.
Подробнее — в нашей статье.
#реклама
О рекламодателе
Понятные описания, точные термины, и «глупые» вопросы — стартовый набор системного аналитика, который ставит хорошие задачи на разработку.
Екатерина Петрова обсудила с инженерами из двух разных компаний их представления о роли и работе аналитиков.
Подробнее — в нашей статье.
#реклама
О рекламодателе
❤1👍1👎1🔥1🤮1
Как читать таблицу маршрутизации в Windows
Как показывает практика, маршрутизация - одна из наиболее сложных тем для начинающих администраторов. Хотя, казалось бы, берем таблицу маршрутов, там все написано.
Но не все умеют правильно читать и понимать там написанное.
Следует запомнить несколько простых правил.
1️⃣ Сначала в таблице ищется маршрут с самой узкой маской. Минимальная маска - 255.255.255.255, максимальная - 0.0.0.0.
2️⃣ Если маршрутов несколько, то берется маршрут с самой маленькой метрикой.
3️⃣ После того, как маршрут найден, следует определить интерфейс выхода, который должен быть расположен в одной из непосредственно присоединенных сетей, т.е. быть доступен на канальном уровне.
Посмотрим на картинку внизу. Если мы хотим пропинговать сами себя, т.е. 192.168.233.154, то для этого сразу будет найден кратчайший маршрут в непосредственно присоединенной сети (зеленый). On-link обозначает непосредственно присоединенную сеть.
Если мы хотим обратиться к ПК из своего сегмента. то нам подойдет маршрут с более широкой маской /24 (желтый).
А если ни одного подходящего маршрута нет? Тогда нам следует использовать маршрут по умолчанию или нулевой маршрут 0.0.0.0/0.
Смотрим, таких маршрутов сразу два. Какой из них использовать? Тот у кого меньше метрика, т.е. на интерфейса 10.20.0.101 Он тоже доступен без маршрутизации.
Если же этого маршрута не будет (отключим VPN), то заработает верхний маршрут с метрикой 25. Но там стоит адрес шлюза - 192.168.233.2. Поэтому идем дальше и ищем маршрут уже для этого адреса.
Поиск такого маршрута производится только среди непосредственно присоединенных сетей и очень скоро мы снова находим нужный маршрут, который помечен желтым.
☝️ Поэтому всегда, составляя и анализируя маршруты, помним - любой маршрут должен приводить в непосредственно присоединенную сеть, иначе он работать не будет.
Почему? Да потому что IP - это 3-й уровень модели OSI - сетевой и нельзя просто так передавать IP-пакеты между ПК. Для того, чтобы это сделать, мы должны опуститься на канальный уровень и вложить их в датафреймы.
А потом еще ниже, на физический, но так глубоко мы копать не будем.
А канальный уровень - это непосредственно присоединенная сеть и только так. Это же ответ на многие вопросы типа: я написал маршрут, а он не работает. В этом случае всегда смотрим, а можем ли мы по нему достичь непосредственно присоединенной сети или нет.
Как показывает практика, маршрутизация - одна из наиболее сложных тем для начинающих администраторов. Хотя, казалось бы, берем таблицу маршрутов, там все написано.
Но не все умеют правильно читать и понимать там написанное.
Следует запомнить несколько простых правил.
1️⃣ Сначала в таблице ищется маршрут с самой узкой маской. Минимальная маска - 255.255.255.255, максимальная - 0.0.0.0.
2️⃣ Если маршрутов несколько, то берется маршрут с самой маленькой метрикой.
3️⃣ После того, как маршрут найден, следует определить интерфейс выхода, который должен быть расположен в одной из непосредственно присоединенных сетей, т.е. быть доступен на канальном уровне.
Посмотрим на картинку внизу. Если мы хотим пропинговать сами себя, т.е. 192.168.233.154, то для этого сразу будет найден кратчайший маршрут в непосредственно присоединенной сети (зеленый). On-link обозначает непосредственно присоединенную сеть.
Если мы хотим обратиться к ПК из своего сегмента. то нам подойдет маршрут с более широкой маской /24 (желтый).
А если ни одного подходящего маршрута нет? Тогда нам следует использовать маршрут по умолчанию или нулевой маршрут 0.0.0.0/0.
Смотрим, таких маршрутов сразу два. Какой из них использовать? Тот у кого меньше метрика, т.е. на интерфейса 10.20.0.101 Он тоже доступен без маршрутизации.
Если же этого маршрута не будет (отключим VPN), то заработает верхний маршрут с метрикой 25. Но там стоит адрес шлюза - 192.168.233.2. Поэтому идем дальше и ищем маршрут уже для этого адреса.
Поиск такого маршрута производится только среди непосредственно присоединенных сетей и очень скоро мы снова находим нужный маршрут, который помечен желтым.
☝️ Поэтому всегда, составляя и анализируя маршруты, помним - любой маршрут должен приводить в непосредственно присоединенную сеть, иначе он работать не будет.
Почему? Да потому что IP - это 3-й уровень модели OSI - сетевой и нельзя просто так передавать IP-пакеты между ПК. Для того, чтобы это сделать, мы должны опуститься на канальный уровень и вложить их в датафреймы.
А потом еще ниже, на физический, но так глубоко мы копать не будем.
А канальный уровень - это непосредственно присоединенная сеть и только так. Это же ответ на многие вопросы типа: я написал маршрут, а он не работает. В этом случае всегда смотрим, а можем ли мы по нему достичь непосредственно присоединенной сети или нет.
👍21❤5🤮1
gf_УФНС_о_поддержке_ФФД_в_ККТ_АВ_нб2025.pdf
283.9 KB
Получил сегодня по официальным каналам письмо ФНС, которое полностью подтверждает все изложенное во вчерашней заметке. А именно:
💬 Изменения в Приказе о ФФД носят ограниченный характер, не требуют масштабных доработок. Более того, большая часть новых тегов, предназначенных для записи информации о безналичных транзакциях в кассовый чек, может не включаться в состав фискальных данных в данной редакции Приказа о ФФД.
Т.е. теги 1234-1238 и 1082 формировать и передавать не нужно. Поэтому вам нужно только прошить кассу и обновить драйвер ККТ. Исключения касаются тех, кто торгует дистанционно, там потребуется дополнительно формировать и передавать 1125, 1187 и 1008.
Также плохая новость для тех, кто думал пересидеть, пересидеть не получится, снова цитирую:
💬 Учитывая изложенное, ФНС России сообщает об отсутствии весомых причин для переноса срока вступления в силу изменений в Приказ о ФФД и необходимости неукоснительного соблюдения его положений с 01.09.2025. Указанные изменения необходимо поддержать до 01.09.2025 и с этой даты исполнять обновленные требования Приказа о ФФД.
Поэтому, кто не успел – времени еще до понедельника, а работы не особо много. Иначе есть вполне реальные риски попасть под штрафные санкции.
💬 Изменения в Приказе о ФФД носят ограниченный характер, не требуют масштабных доработок. Более того, большая часть новых тегов, предназначенных для записи информации о безналичных транзакциях в кассовый чек, может не включаться в состав фискальных данных в данной редакции Приказа о ФФД.
Т.е. теги 1234-1238 и 1082 формировать и передавать не нужно. Поэтому вам нужно только прошить кассу и обновить драйвер ККТ. Исключения касаются тех, кто торгует дистанционно, там потребуется дополнительно формировать и передавать 1125, 1187 и 1008.
Также плохая новость для тех, кто думал пересидеть, пересидеть не получится, снова цитирую:
💬 Учитывая изложенное, ФНС России сообщает об отсутствии весомых причин для переноса срока вступления в силу изменений в Приказ о ФФД и необходимости неукоснительного соблюдения его положений с 01.09.2025. Указанные изменения необходимо поддержать до 01.09.2025 и с этой даты исполнять обновленные требования Приказа о ФФД.
Поэтому, кто не успел – времени еще до понедельника, а работы не особо много. Иначе есть вполне реальные риски попасть под штрафные санкции.
👌5