Я не совсем тогда понимаю, в чём именно вы видите нарушение приватности в осуществлении торговой сделки:
продавец знает, что вы купили и за сколько; ОФД знает, что купили, но не знает кто; банк знает за сколько купили, но не знает что.
Возможно ФНС может сопоставить платёж и чек, но я в этом сомневаюсь.
На мой взгляд баланс между требованиями ФНС и приватностью соблюдён.
Ну так есть разные уровни приватности, ОФД немного и у них довольно обезличенная информация, так просто привязать её к человеку не просто. Плюс это лицензируемая деятельность, так что уверенности в сохранности чуть больше.
В полученном чеке содержится вся информация, но приватность не нарушается, так как для доступа к ней нужен выданнный чек, который получает только тот, кто и так знает, что в нём.
Если реквизиты человек решит разделить с третьей стороной, то да, третья сторона может получить полную информацию.
Поэтому с приватностью здесь всё хорошо.
Тут как раз в тему недавно прошла новость, что Allwinner собирается произвести 50 миллионов процессоров, в том числе и XuanTie 910 (16-ядерный RISC-V от Алибабы).
Есть шанс на дополнительный толчок к развитию и популяризации этой архитектуры.
Бывает, что один модуль на десятки тысяч строк кода расширить в смысле смены архитектуры/увеличения функционала проще, чем демонтировать уже существующую архитектуру и пересоздать её заново.
Расширяемость это не только код, это ещё и принципы работы системы, которые необходимо поддерживать при изменении кода системы. Соответственно, если никто ещё задуманные интерфейсы расширяемости не использует, то возрастает цена изменения, так как надо больше факторов проверить на соответствие концепции расширяемости.
Также довольно часто ненужная расширяемость выливается в постоянные затраты времени выполнения: лишние данные занимают место, ненужные события вызываются, выполняются проверки никогда не устанавливаемых условий, неисполняемый код отравляет кэш инструкций и т. д.
Расширяемость это попытка угадать будущие требования, которая в случае неудачи может привести к громоздкой и неподходящей архитектуре, которую просто по определению очень тяжело сменить.
Я за всю свою карьеру видел множество примеров ошибочных прогнозов будущих требований, и всего два примера, когда основатели архитектуры верно угадали, что потребуется. И в этих обоих случаях у них был большой опыт работы в данной конкретной области.
Под примечаниями я подразумевал сноски. И для них лучше формата pdf не придумаешь: размер и сами шрифты выбраны мною, размер страницы идеально соответствует размеру экрана, есть поиск, переносы стоят там, где мне нужно, и т. д. Вот, например, растеризовал страницу случайной книги:
Соответственно, когда у меня была другая читалка (Sony PRS-500), я для неё формировал книгу с другими параметрами. Аналогично для художественной литературы я сейчас делаю mobi или ePub-варианты представления, в зависимости от целевого устройства. Никакой другой из распространённых форматов такого удобства не представляет.
Я однажды встретил PDF, где текст был набран побуквенно: т. е. бралась буква, например, «А» и размещалась по всей странице, потом бралась следующая, например, «Б» и т. д.
fb2 это формат хранения и исходник для преобразования в файл представления. Я люблю читать книги в привычном и удобном для себя виде. Поэтому если я читаю на kindle, то преобразую в .mobi, если книга с многими примечаниями, то я делаю из неё .pdf. Непосредственно .fb2 я почти никогда для чтения не использую.
А из сложностей, например, это когда текст в файле идёт обычными тегами абзацев, где выделение курсивом или жирным делается стилями, сменой шрифта. Ещё любят делать цитаты и отступы стилями. Почти каждая книга уникальна в этом отношении, мне ещё не удалось сделать вариант конверсии, который бы всё мог сделать автоматически.
Я довольно часто сталкиваюсь с задачей преобразования из ePub в FB2 (в личных целях), так вот это очень непросто, так как теги очень редко встречаются, обычно всё стилизуется через CSS. А уж автоматизированно восстановить структуру книги совсем невозможно.
А мне он и не нужен, свою работу он выполнил, важные ресурсы освобождены, известные мне ссылки на него сброшены, а память будет переиспользована тогда, когда это будет безопасно — когда не останется живых ссылок на этот объект.
Я с этим абсолютно согласен. Наш проект (тогда это было около 1Гб Си++ кода, не считал строки) только за счёт строгой дисциплины и выживал. Проблемы возникали из-за того, что его продавали под разработку других систем, при взаимодействии с которыми это и происходило.
В языках с GC лучше разделять время жизни объекта и время жизни памяти, которое он занимает. Так как жизнью объекта надо явно управлять, а GC обеспечивает самое главное — консистентность памяти и наблюдаемость системы, потому что если при сбое можно испортить память где-то, то система не может быть наблюдаемой по определению.
А .NET это одна из систем, которые, как и способ интеграции в неё, были просто даны и изменить их нельзя.
Как и объекты, которые передавались нам взаимодействие и не хранить ссылки на которые мы просто не могли.
Микросервисы, как отдельные инстанции части ПО были, но только там, где это позволяла инфраструктура заказчиков.
И после всех этих проблем с циклами, ошибками с доступом по памяти, и прочими прелестями неуправляемых языков, те гарантии локальности и живости объектов, которые дают управляемые среды с их сборщиками мусора, это просто глоток свежего воздуха.
Но это всё всё равно отвлечение от моего первоначального заявления, что сборка мусора как трассировкой, так и подсчётом ссылок это одно и то же. Если участвующие графы объектов большие и с гибкой структурой, то нельзя гарантировать время освобождения ресурса.
Программисты программируют не системы, а подсистемы. Контролировать вышележащую систему удаётся только в редких случаях, когда программы небольшие. А если системы большие, развиваются и контролируются разными участниками, про многих из которых ты даже не знаешь, когда твоей подсистеме могут передавать объекты, реализацию которых ты, возможно, никогда не увидишь, даже в пределах одной организации. Тогда об никакой унификации говорить нельзя, а управлять временем жизни объектов надо.
Ещё одна проблема, которая возникает при подсчёте ссылок: это неправильный их учёт, лишнее освобождение или увеличение, и это несмотря на использование смышлёных указателей. Большое количество программистов разного уровня, неконтролируемый сторонний код, резко усложняет процесс разработки на счётчиках. .Net был гораздо наблюдаемей и проблем от него меньше.
У меня был опыт работы с большой унаследованной системой, в которой использовались .Net, С++ и куча COM-компонентов, у части которых исходников не было вообще.
Циклы по счётчикам возникали постоянно, причём граф зависимостей проходил по всем видам рантаймов, поэтому я вживую наблюдал, как при уменьшении счётчика внезапно освобождалось огромное дерево зависимостей, и возникала пауза больше минуты.
Проблема была настолько актуально, что я разработал трассировщик зависимостей а-ля Boehm GC, который шерстил память и пытался отстроить дерево зависимостей.
Поэтому говорить, что GC на счётчиках локален, в общем смысле, нельзя.
Подсчёт ссылок это тот же самый GC с непредсказуемым временем исполнения. A unified theory of garbage collection — любопытная работа, где говорится, что между ними нет чёткой разницы, один вариант просто перетекает в другой.
Это был один человек, причём убеждённый питонист, вот, что он (James Tauber) о себе пишет:
Python is my programming language of choice. I've been using it since 1998.
I am a member of the Python Software Foundation and previously served on its Board of Directors. In 2007 and 2008, I was the organizational administrator for the Python Software Foundation's projects in the Summer of Code.
I've given numerous Python-related talks from local meetups to keynoting PyCon Taiwan in Jun 2012.
Но тем не менее, столкнувшись с трудностями при разработке и отладке, он сменил язык разработки на Java и переписал его весь.
Вспомнил один проект, который стартовал как проект на питоне, но через некоторое время автор перешёл на Java: Apache FOP. Ссылка на старые новости (архив).
Я не совсем тогда понимаю, в чём именно вы видите нарушение приватности в осуществлении торговой сделки:
продавец знает, что вы купили и за сколько; ОФД знает, что купили, но не знает кто; банк знает за сколько купили, но не знает что.
Возможно ФНС может сопоставить платёж и чек, но я в этом сомневаюсь.
На мой взгляд баланс между требованиями ФНС и приватностью соблюдён.
Ну так есть разные уровни приватности, ОФД немного и у них довольно обезличенная информация, так просто привязать её к человеку не просто. Плюс это лицензируемая деятельность, так что уверенности в сохранности чуть больше.
В полученном чеке содержится вся информация, но приватность не нарушается, так как для доступа к ней нужен выданнный чек, который получает только тот, кто и так знает, что в нём.
Если реквизиты человек решит разделить с третьей стороной, то да, третья сторона может получить полную информацию.
Поэтому с приватностью здесь всё хорошо.
Тут как раз в тему недавно прошла новость, что Allwinner собирается произвести 50 миллионов процессоров, в том числе и XuanTie 910 (16-ядерный RISC-V от Алибабы).
Есть шанс на дополнительный толчок к развитию и популяризации этой архитектуры.
Бывает, что один модуль на десятки тысяч строк кода расширить в смысле смены архитектуры/увеличения функционала проще, чем демонтировать уже существующую архитектуру и пересоздать её заново.
Расширяемость это не только код, это ещё и принципы работы системы, которые необходимо поддерживать при изменении кода системы. Соответственно, если никто ещё задуманные интерфейсы расширяемости не использует, то возрастает цена изменения, так как надо больше факторов проверить на соответствие концепции расширяемости.
Также довольно часто ненужная расширяемость выливается в постоянные затраты времени выполнения: лишние данные занимают место, ненужные события вызываются, выполняются проверки никогда не устанавливаемых условий, неисполняемый код отравляет кэш инструкций и т. д.
Расширяемость это попытка угадать будущие требования, которая в случае неудачи может привести к громоздкой и неподходящей архитектуре, которую просто по определению очень тяжело сменить.
Я за всю свою карьеру видел множество примеров ошибочных прогнозов будущих требований, и всего два примера, когда основатели архитектуры верно угадали, что потребуется. И в этих обоих случаях у них был большой опыт работы в данной конкретной области.
А видели статью Flattening quadratic Béziers, где автор предложил способ не рекурсивного разбиения квадратичных кривых, а аналитический метод?
Под примечаниями я подразумевал сноски. И для них лучше формата pdf не придумаешь: размер и сами шрифты выбраны мною, размер страницы идеально соответствует размеру экрана, есть поиск, переносы стоят там, где мне нужно, и т. д. Вот, например, растеризовал страницу случайной книги:
Соответственно, когда у меня была другая читалка (Sony PRS-500), я для неё формировал книгу с другими параметрами. Аналогично для художественной литературы я сейчас делаю mobi или ePub-варианты представления, в зависимости от целевого устройства. Никакой другой из распространённых форматов такого удобства не представляет.
Я однажды встретил PDF, где текст был набран побуквенно: т. е. бралась буква, например, «А» и размещалась по всей странице, потом бралась следующая, например, «Б» и т. д.
fb2 это формат хранения и исходник для преобразования в файл представления. Я люблю читать книги в привычном и удобном для себя виде. Поэтому если я читаю на kindle, то преобразую в .mobi, если книга с многими примечаниями, то я делаю из неё .pdf. Непосредственно .fb2 я почти никогда для чтения не использую.
А из сложностей, например, это когда текст в файле идёт обычными тегами абзацев, где выделение курсивом или жирным делается стилями, сменой шрифта. Ещё любят делать цитаты и отступы стилями. Почти каждая книга уникальна в этом отношении, мне ещё не удалось сделать вариант конверсии, который бы всё мог сделать автоматически.
Я довольно часто сталкиваюсь с задачей преобразования из ePub в FB2 (в личных целях), так вот это очень непросто, так как теги очень редко встречаются, обычно всё стилизуется через CSS. А уж автоматизированно восстановить структуру книги совсем невозможно.
А мне он и не нужен, свою работу он выполнил, важные ресурсы освобождены, известные мне ссылки на него сброшены, а память будет переиспользована тогда, когда это будет безопасно — когда не останется живых ссылок на этот объект.
Я с этим абсолютно согласен. Наш проект (тогда это было около 1Гб Си++ кода, не считал строки) только за счёт строгой дисциплины и выживал. Проблемы возникали из-за того, что его продавали под разработку других систем, при взаимодействии с которыми это и происходило.
В языках с GC лучше разделять время жизни объекта и время жизни памяти, которое он занимает. Так как жизнью объекта надо явно управлять, а GC обеспечивает самое главное — консистентность памяти и наблюдаемость системы, потому что если при сбое можно испортить память где-то, то система не может быть наблюдаемой по определению.
А .NET это одна из систем, которые, как и способ интеграции в неё, были просто даны и изменить их нельзя.
Как и объекты, которые передавались нам взаимодействие и не хранить ссылки на которые мы просто не могли.
Микросервисы, как отдельные инстанции части ПО были, но только там, где это позволяла инфраструктура заказчиков.
И после всех этих проблем с циклами, ошибками с доступом по памяти, и прочими прелестями неуправляемых языков, те гарантии локальности и живости объектов, которые дают управляемые среды с их сборщиками мусора, это просто глоток свежего воздуха.
Но это всё всё равно отвлечение от моего первоначального заявления, что сборка мусора как трассировкой, так и подсчётом ссылок это одно и то же. Если участвующие графы объектов большие и с гибкой структурой, то нельзя гарантировать время освобождения ресурса.
Программисты программируют не системы, а подсистемы. Контролировать вышележащую систему удаётся только в редких случаях, когда программы небольшие. А если системы большие, развиваются и контролируются разными участниками, про многих из которых ты даже не знаешь, когда твоей подсистеме могут передавать объекты, реализацию которых ты, возможно, никогда не увидишь, даже в пределах одной организации. Тогда об никакой унификации говорить нельзя, а управлять временем жизни объектов надо.
Циклы по счётчикам возникали постоянно, причём граф зависимостей проходил по всем видам рантаймов, поэтому я вживую наблюдал, как при уменьшении счётчика внезапно освобождалось огромное дерево зависимостей, и возникала пауза больше минуты.
Проблема была настолько актуально, что я разработал трассировщик зависимостей а-ля Boehm GC, который шерстил память и пытался отстроить дерево зависимостей.
Поэтому говорить, что GC на счётчиках локален, в общем смысле, нельзя.
A unified theory of garbage collection — любопытная работа, где говорится, что между ними нет чёткой разницы, один вариант просто перетекает в другой.
Но тем не менее, столкнувшись с трудностями при разработке и отладке, он сменил язык разработки на Java и переписал его весь.
Ссылка на старые новости (архив).