Не, ну то, что автор первым делом начинает сравнивать сабж с SQLite, которая вообще не столько СУБД, сколько библиотека доступа к данным с SQL-синтаксисом - для многих читателей это будет сигналом закрыть статью и не открывать её больше. Да, ниже уже упоминаются Oracle и MS SQL Server, но до этого места надо ещё дойти. Понятно, что автор хотел упростить себе задачу (преимущества PostgreSQL перед SQLite, разумеется, показать, куда легче), но эффект, боюсь, для читателей, которые что-то знают про базы данных, получился прямо противоположным. Если бы сразу начать сравнение Postgre vs Oracle - статья бы выглядела более серьёзной. :)
Упоминание NoSQL-решений... Вообще, это крайне холиварная тема, но правильнее всего было бы упомянуть, что реляционные и нереляционные СУБД можно не противопоставлять, а сочетать. И в некоторых крупных проектах так и делают (если не ошибаюсь, про авито был такой доклад, и кажется, там PostgreSQL и упоминался, но это неточно). А так да, если человек не собирается делать миллионы транзакций в минуту и сразу тащит в рот NoSQL исключительно из соображений того, что он сэкономит время на проектировании структуры данных - он делает неправильно, тут соглашусь с автором.
Наконец, если кто-то затевает долгоиграющий проект с сильно более чем одним внедрением - ему стоит подумать над тем, чтобы сделать СУБД "сменной". У меня, например, есть опыт разработки проекта, где хранилище могло быть либо клиент-серверным (PostgreSQL), либо локальным (внутренняя СУБД - SQLite плюс выгрузка-загрузка в XML либо JSON, для пользователя локального варианта это выглядит просто как работа с XML-файлами), при этом по необходимости можно было легко перейти от одного варианта к другому, просто загрузив XML в PostgreSQL утилитой импорта. При этом порядка 90% SQL-запросов работали одинаково на обеих СУБД (кое-где таки пришлось сделать СУБД-специфичные ветки и то, главным образом, для оптимизации).
"Кормить надо лучше, они и не улетят" (из старой рекламы).
Автору статьи спасибо за хороший термин, наверное, можно использовать его в резюме. Я как раз тот самый старый программист, который упорото хочет заниматься разработкой и которого в тимлиды калачом не заманишь.
Журналисты пишут, что руководители больших компаний не должны решать, кто достоин работы в эпоху нейросетей, и не могут открыто рассказывать, что некоторым профессиям не стоило существовать.
А под названием Lemon есть ещё вполне живой проект генерации парсеров на замену YACC/Bison. Я даже удивился, думал, это про него, при чём, думаю, тут дичь.
А тут, оказывается, кто-то название для фреймворка неосмотрительно выбрал.
У меня в студенчестве была книжка по сабжу Фролова и Олюнина, зачитанная до отрыва корешка. Интересовался, планировал на нём писать, но поскольку до рабочего компилятора так и не добрался, в итоге оседлал сначала объектный Паскаль, а потом плюсы. Всегда удивлялся, почему в современных языках не все очевидные и удобные вещи оттуда реализовали. Кажется, только в Go и последних стандартах плюсов лёд тронулся.
свободно распространяемые компиляторы Iron Spring PL/I Питера Фласса для Linux (i386)
Я по сайту не понял, оно в исходниках распространяется (и если да, то какая лицензия) или только бинарно?
Фанаты со всего мира, услышав новость о Терри, начали размещать посвящения в его честь. Несмотря на то, что этот человек явно прожил тяжёлую жизнь, осложнённую болезнью, люди вспоминали всё лучшее, что у него было, и желали ему всего хорошего.
Вот интересно, а поддержку при жизни ему как-то можно было оказать? И что за моча должна быть в головах у людей, которые издеваются над талантливым, но больным человеком? Да даже если и не талантливым... Периодически, чтобы не потерять веру в людей, очень хочется думать, что интернет-тролли - это отдельный биологический вид, к несчастью, слишком схожий с человеком. Да, я в курсе, что "интернет" здесь лишнее слово, интернет просто облегчил им жизнь...
GPL здесь не ради свободы, а чтобы заставить разработчиков, кто не хочет отрывать код своих приложений, покупать коммерческую версию.
Зачем же тогда так сложно было? Для этого совсем не нужна GPL, для этого можно просто продавать коммерческую версию, где нужны исходники - передавать их покупателям под несвободной лицензией. По такой модели Unreal Engine работает, например, вполне успешно.
Нет, GPL именно что для свободы, и чтобы примирить свободу с коммерцией, и чтобы второе не сожрало первое в том числе.
Надо же, а мне всего 2 года назад (не 20) прислали для отладки моего редактора контактов файл .VCF, сгенерированный аутлуком. И там, внезапно, оказалась cp1251. Хотя во всех RFC на vCard прописан UTF8.
Разработчики Qt вот тоже, видимо, 20 лет бнопни не видели. И в Qt 6.0 выкинули все неюникодные кодировки, а заодно и класс QTextCodec перевели в устаревшие. Уже в 6.4 их убедили вернуть поддержку всего, что поддерживает ICU... но уже в новые классы, которые изначально были заточены только на юникод. Козу купили, козу продали, но несовместимостей успели наломать.
Кроме iconv, есть ещё enca. Iconv есть в любом линуксе, а enca надо ещё поискать и скорее всего собрать, зато в нём есть АВТООПРЕДЕЛЕНИЕ! Я как-то в рамках рефакторинга очень-очень старого легаси-проекта (часть авторов писали в 1251, часть в КОИ8) натравил на дерево исходников связку find и enca, и она успешно всё перевела в UTF8.
Вот, кажется оно (хотя я пользовался бинарной сборкой одного из отечественных дистрибутивов):
Ну сегодня можно, завтра кто-нибудь "там" сообразит, что это дыра, которую не успели заткнуть.
В любом случае я бы на месте автора статьи сначала потыкал бы Гимп, который благодаря лицензии неубиваем и работает на всём, что шевелится. Но автор, похоже, даже не задавался таким вопросом, а сразу озадачился перелезанием с одного ржавого юридического гвоздя на другой.
Вы сразу привнесли в формулировку слово "должен". Ну во-первых, далеко не всегда надо допиливать, мне гимпа для личных задач в целом хватает (хотя по мелочи там есть что доработать, безусловно). Во-вторых, доработать свободный продукт - более благодарная задача, чем с нуля пилить закрытый.
В области офисных пакетов есть почти идеальная история - это опыт нижегородской команды разработчиков. За рубеж его продаёт латвийская компания под названием OnlyOffice, в России продаётся как Р7-Офис. При этом исходники онлиофиса открыты. Ах, если бы с графическими пакетами было что-то подобное...
пока мы решаем вопросы с продлением подписки через зарубежных друзей или вспоминаем опыт пиратства
Но первый же рассмотренный автором продукт - ФотоМОНТАЖ - работает только в Windows, третий - Movavi Photo Editor - в Windows и macOS. Только AliveColors может похвастаться тремя поддерживаемыми операционками. Вопрос: Почему невозможность купить продукты Adobe в России автора интересует, а про Microsoft у него вопрос не возникает?
Если же ставить вопрос последовательно, начать можно было бы с другого. Чего именно автору не хватает в полностью открытом GIMP, который работает не только в Windows, но и в почти любом распространённом линуксе, включая, разумеется, российские? И это международный проект, среди участников которого есть и россияне (хотя по моему сугубо субъективному мнению, их могло быть и побольше). Недостатки у GIMP, разумеется, есть, но есть мнение, что большинство ищущих "аналог Фотошопа" до них просто не дошли и дойдут не скоро. И вот в то, чего там не хватает, можно и вложиться.
Не, ну то, что автор первым делом начинает сравнивать сабж с SQLite, которая вообще не столько СУБД, сколько библиотека доступа к данным с SQL-синтаксисом - для многих читателей это будет сигналом закрыть статью и не открывать её больше. Да, ниже уже упоминаются Oracle и MS SQL Server, но до этого места надо ещё дойти. Понятно, что автор хотел упростить себе задачу (преимущества PostgreSQL перед SQLite, разумеется, показать, куда легче), но эффект, боюсь, для читателей, которые что-то знают про базы данных, получился прямо противоположным. Если бы сразу начать сравнение Postgre vs Oracle - статья бы выглядела более серьёзной. :)
Упоминание NoSQL-решений... Вообще, это крайне холиварная тема, но правильнее всего было бы упомянуть, что реляционные и нереляционные СУБД можно не противопоставлять, а сочетать. И в некоторых крупных проектах так и делают (если не ошибаюсь, про авито был такой доклад, и кажется, там PostgreSQL и упоминался, но это неточно). А так да, если человек не собирается делать миллионы транзакций в минуту и сразу тащит в рот NoSQL исключительно из соображений того, что он сэкономит время на проектировании структуры данных - он делает неправильно, тут соглашусь с автором.
Наконец, если кто-то затевает долгоиграющий проект с сильно более чем одним внедрением - ему стоит подумать над тем, чтобы сделать СУБД "сменной". У меня, например, есть опыт разработки проекта, где хранилище могло быть либо клиент-серверным (PostgreSQL), либо локальным (внутренняя СУБД - SQLite плюс выгрузка-загрузка в XML либо JSON, для пользователя локального варианта это выглядит просто как работа с XML-файлами), при этом по необходимости можно было легко перейти от одного варианта к другому, просто загрузив XML в PostgreSQL утилитой импорта. При этом порядка 90% SQL-запросов работали одинаково на обеих СУБД (кое-где таки пришлось сделать СУБД-специфичные ветки и то, главным образом, для оптимизации).
"Кормить надо лучше, они и не улетят" (из старой рекламы).
Автору статьи спасибо за хороший термин, наверное, можно использовать его в резюме. Я как раз тот самый старый программист, который упорото хочет заниматься разработкой и которого в тимлиды калачом не заманишь.
Не нашёл в статье информации о лицензии самой SerenityOS. Восполняю пробел - там двухпунктная BSD.
Одобряю этих журналистов.
А под названием Lemon есть ещё вполне живой проект генерации парсеров на замену YACC/Bison. Я даже удивился, думал, это про него, при чём, думаю, тут дичь.
А тут, оказывается, кто-то название для фреймворка неосмотрительно выбрал.
Мне показалось, что первые два проекта, особенно второй - отсылка не столько к HTML, сколько к XML.
P.S. А вот, выше уже про SGML подметили :)
"Выложат" и "утекали" это понятия совсем из разных реальностей, вообще-то.
Исходники под GPL плохо перевариваются Микрософтом, вот был бы MIT какой-нибудь - другое дело.
И это хорошо, пусть проект сохраняет самобыность!
Я правильно понимаю, что это то, на основе чего потом был сделан упомянутый в статье PL/1-КТ ?
У меня в студенчестве была книжка по сабжу Фролова и Олюнина, зачитанная до отрыва корешка. Интересовался, планировал на нём писать, но поскольку до рабочего компилятора так и не добрался, в итоге оседлал сначала объектный Паскаль, а потом плюсы. Всегда удивлялся, почему в современных языках не все очевидные и удобные вещи оттуда реализовали. Кажется, только в Go и последних стандартах плюсов лёд тронулся.
Я по сайту не понял, оно в исходниках распространяется (и если да, то какая лицензия) или только бинарно?
Вот это, как всегда:
Вот интересно, а поддержку при жизни ему как-то можно было оказать? И что за моча должна быть в головах у людей, которые издеваются над талантливым, но больным человеком? Да даже если и не талантливым... Периодически, чтобы не потерять веру в людей, очень хочется думать, что интернет-тролли - это отдельный биологический вид, к несчастью, слишком схожий с человеком. Да, я в курсе, что "интернет" здесь лишнее слово, интернет просто облегчил им жизнь...
Абсолютно солидарен.
Зачем же тогда так сложно было? Для этого совсем не нужна GPL, для этого можно просто продавать коммерческую версию, где нужны исходники - передавать их покупателям под несвободной лицензией. По такой модели Unreal Engine работает, например, вполне успешно.
Нет, GPL именно что для свободы, и чтобы примирить свободу с коммерцией, и чтобы второе не сожрало первое в том числе.
Надо же, а мне всего 2 года назад (не 20) прислали для отладки моего редактора контактов файл .VCF, сгенерированный аутлуком. И там, внезапно, оказалась cp1251. Хотя во всех RFC на vCard прописан UTF8.
Разработчики Qt вот тоже, видимо, 20 лет бнопни не видели. И в Qt 6.0 выкинули все неюникодные кодировки, а заодно и класс QTextCodec перевели в устаревшие. Уже в 6.4 их убедили вернуть поддержку всего, что поддерживает ICU... но уже в новые классы, которые изначально были заточены только на юникод. Козу купили, козу продали, но несовместимостей успели наломать.
Кроме iconv, есть ещё enca. Iconv есть в любом линуксе, а enca надо ещё поискать и скорее всего собрать, зато в нём есть АВТООПРЕДЕЛЕНИЕ! Я как-то в рамках рефакторинга очень-очень старого легаси-проекта (часть авторов писали в 1251, часть в КОИ8) натравил на дерево исходников связку find и enca, и она успешно всё перевела в UTF8.
Вот, кажется оно (хотя я пользовался бинарной сборкой одного из отечественных дистрибутивов):
https://github.com/nijel/enca
Ну сегодня можно, завтра кто-нибудь "там" сообразит, что это дыра, которую не успели заткнуть.
В любом случае я бы на месте автора статьи сначала потыкал бы Гимп, который благодаря лицензии неубиваем и работает на всём, что шевелится. Но автор, похоже, даже не задавался таким вопросом, а сразу озадачился перелезанием с одного ржавого юридического гвоздя на другой.
Вы сразу привнесли в формулировку слово "должен". Ну во-первых, далеко не всегда надо допиливать, мне гимпа для личных задач в целом хватает (хотя по мелочи там есть что доработать, безусловно). Во-вторых, доработать свободный продукт - более благодарная задача, чем с нуля пилить закрытый.
В области офисных пакетов есть почти идеальная история - это опыт нижегородской команды разработчиков. За рубеж его продаёт латвийская компания под названием OnlyOffice, в России продаётся как Р7-Офис. При этом исходники онлиофиса открыты. Ах, если бы с графическими пакетами было что-то подобное...
Начало интриговало:
Но первый же рассмотренный автором продукт - ФотоМОНТАЖ - работает только в Windows, третий - Movavi Photo Editor - в Windows и macOS. Только AliveColors может похвастаться тремя поддерживаемыми операционками. Вопрос: Почему невозможность купить продукты Adobe в России автора интересует, а про Microsoft у него вопрос не возникает?
Если же ставить вопрос последовательно, начать можно было бы с другого. Чего именно автору не хватает в полностью открытом GIMP, который работает не только в Windows, но и в почти любом распространённом линуксе, включая, разумеется, российские? И это международный проект, среди участников которого есть и россияне (хотя по моему сугубо субъективному мнению, их могло быть и побольше). Недостатки у GIMP, разумеется, есть, но есть мнение, что большинство ищущих "аналог Фотошопа" до них просто не дошли и дойдут не скоро. И вот в то, чего там не хватает, можно и вложиться.
Наверное, после слова "разрабатываю" стоит таки поставить запятую, иначе могут очень-очень неправильно понять. "Казнить нельзя помиловать".
Если что - это шутка. Грустная.
Я не очень понял, при чём тут "взломал" и "реверс". Код Watcom же открыли 20 лет назад?