Добрый день знатоки С++ и просто аналитики лора.

Появилась некая проблема. Несколько лет назад девочка написала программу. В среде С билдера, далее в ембракадере... Программа успешно эксплуатировалась достаточное количество лет. Девочка ушла в декрет на неведомый срок. Встал вопрос о внесении изменений в программу, а лицензия ембракадеры или закончилась, или еще какая фигня (на комп не установить с СД). Покупать новую из-за изменения нескольких строк в программе как-то не возбуждает, да ветвь тупиковая, на мой взгляд.

Вот и вопрос. Можно проект собрать, а еще лучше перенести в другую систему разработки. Желательно Visual Studio 2010 (у нас тут лицензий на нее множество).
Сам я на с++ не работал уже лет 15, так что почти все забыл, да и не слежу за развитием платформ С++. Может в еклипси или нетбин проект можно перенести? Может триальной версией ембракадеро воспользоваться? Вот только у нас версия была от 2009 года, а на сайте предлагают Embarcadero RAD Studio XE4 Architect - 30 day trial. Не будет ли проблем с переносом, как это было при переходе на версию от 2009 года.

В общем вопросов до фига, ответов мало. Посоветуйте кто что может.

Да! Проект под офтопик.

C клавиатуры вводятся координаты точек на плоскости в виде строк, представляющих пару в формате (х,у). Координаты должны быть извлечены и помещены в вектор точек (точка - пользовательский тип данных структура). Вычислить и вывести расстояние от всех точек до первой точки.

--------- Похоже, задача решается через т. Пифагора sqrt((x2-x1)^2+(y2-y1)^2). Как приплести сюда структуры?

В общем сегодня юзверьша что-то сделала, что полетели иксы,прав нет, в кде может только картинку рабочего стола сменить.В логи лезть не стал,восстановил систему и пошёл дальше болтать с тестировщицами. Но всё же как можно сломать иксы, чтобы нельзя было запустить kde?Ваши догадки.KDE 4.12 ,всё дефолтно кроме темы и фона рабочего стола.....

Сейчас хорошо распиарены примеры того, как люди с навыками в IT применяли эти навыки для знакомств, например http://on.ted.com/AmyWebb и http://habrahabr.ru/post/210198/ . В силу высокоспецифических требований есть необходимость широкоформатного скрининга, чтобы максимизировать вероятность успеха. Технически единственным подходящим источником данных является ресурс vk.com, его и предполагается использовать. Вопрос: кто из русскоязычной аудитории выполнял подобные скрининги и каковы результаты (и наработанный опыт) ?

На одной из систем journal отъедает месте больше, чем ему сказано:

[root@v0ws ~]# journalctl --disk-usage
Journals take up 110.9M on disk.

[Journal]
#Storage=auto
#Compress=yes
#Seal=yes
#SplitMode=login
#RateLimitInterval=10s
#RateLimitBurst=200
SystemMaxUse=50M
#SystemKeepFree=
#SystemMaxFileSize=
#RuntimeMaxUse=
#RuntimeKeepFree=
#RuntimeMaxFileSize=
#MaxRetentionSec=
#MaxFileSec=1month
#ForwardToSyslog=yes
#ForwardToKMsg=no
#ForwardToConsole=no
#TTYPath=/dev/console
#MaxLevelStore=debug
#MaxLevelSyslog=debug
#MaxLevelKMsg=notice
#MaxLevelConsole=info

Содержимое /var/log/journal/ дропал, все равно забивает больше положенного. Арчвики по этому поводу говорит так:

The maximum size of the persistent journal can be controlled by SystemMaxUse in /etc/systemd/journald.conf

Где грабли?

Ъ:
Житель Вологды, публиковавший на своей странице в соцсети «ВКонтакте» видео в жанре хентай, был осуждён Вологодским городским судом на три года условно.

!Ъ:
http://lenta.ru/news/2014/03/03/toons/

Только что стало известно, что на бета-канале Portal 2 в Steam стала доступна версия и для Linux.

Portal 2 является продолжением Portal от Valve. Игра представляет собой головоломку для решения которой у Вас есть специальное устройство создающее 2 телепорта - вход и выход. Кроме продолжения сюжетной линии для одиночной игры во второй части Portal был добавлен кооператив со своей историей.

В Workshop доступны дополнительные карты-головоломки от любителей.

Сообщить об имеющихся багах или посмотреть на существующие можно здесь: https://github.com/ValveSoftware/portal2/issues.

>>> Подробности

Американские ученые-физики в течение нескольких лет изучали концепцию, согласно которой черные дыры могут населять цивилизации, похожие на человечество. Черные дыры − возможно, одна из самых разрушительных сил во Вселенной.

Но группа физиков-теоретиков под руководством Никодема Поплавского из Университета Нью-Хейвена выдвинула версию, что человечество живет в своей собственной черной дыре. Но, как утверждает концепция, если мы попадем в черную дыру в центре Млечного Пути, то можем оказаться в параллельной Вселенной.

Согласно теории Эйнштейна, центр черной дыры – бесконечно плотный и бесконечно малый. Но современные физики уверены, что в природе бесконечности не может быть. Согласно теории Никодема Поплавского, в центре находится что-то маленькое, но не бесконечное. В основе теории доктора Поплавского лежит убеждение, что «семя» жизни Вселенной было сформировано внутри черной дыры и выброшено при Большом взрыве.

По версии ученых-физиков, это «семя» было меньше всех известных маленьких частиц, но его мощность вызвала производство других частиц: в настоящее время галактик, солнечной системы, планет и людей.

Доктор Поплавский предполагает, что черная дыра может представлять собой «дверь» между двумя Вселенными. Он считает, что если попасть в черную дыру в центре Млечного Пути, то, возможно, перенестись в параллельную Вселенную. Но пока это только теория.


http://argumenti.ru/science/2014/02/321126

или http://ria.ru/space/20140222/996285501.html

Делаю пост сюда, чтобы линковать его людям. Ибо на лоре есть разметка

Ситуация: Живём много лет на sysvinit, появляются всякие openrc и upstart, на которых работают две системы их большого количества. Появляется systemd и сразу большое количество систем переходят на него. Почему? Обьясню на примере debian, тестовой ветки и systemd из этой же ветки.

Почему появилось желание поменять sysvinit на чтото другое?

1) Структура скриптов для sysvinit подразумевает только возможность запуска скриптов с флагами start и stop. Внутреннее устройство скрипта ЦЕЛИКОМ на совести разработчика. Конечно это не повод считать что все скрипты для sysv говно, но всётаки встречаются такие экземпляры, что хочется просто плакать, когда их читаешь. Особенно изза того, что большую часть логики слежением за стотоянем службы пишется на баше. Хотя нынче половина инит скриптов завязанны на start-stop-service. В итоге - каша.

2)Никаких средств для учёта очерёдности запуска сервисов и паралельной их загрузки. Да, есть insserv, только оно ещё больше каши добавляет в скрипты инициализации.

Почему не upstart?

Уже несколько лет в дебиане висит, и ещё не пыталось стать стандартной системой инициализации. В нынешней ситуации, когда говорят о фичах, которые уже есть в других системах инициализации - говорят - «пфф, мы можем тоже такое написать» (тот же cgroup). В итоге функционал апстарта в текущем его состоянии ушёл не дальше sysvinit+insserv+start-stop-daemon. Зато хипстер-аура вокруг него просто знатная.

Почему не openrc?

Оно ещё старше, чем upstart, но разговоры о нём толком начались только при выборе между upstart и systemd. В итоге оно на бумаге конечно лучше чем systemd, но практически это даже проверить не возможно. Некая мифическая сущность, сферическая и в вакууме.

Почему systemd?

1) Он уже работает в тестинге, и не полагется на fallback на sysvinit. Когда я последний раз пробовал upstart без sysvinit скриптов он не работал, и все его преимущества скатывались в ничто. Просто не использовались. В итоге ситуация выглядит так:

systemd - сначала сделали поддержу, потом ещё предложили как стандарт.

openrc и upstart - сначала предложили, а поддержки нету, никакой. Вот если выберут - то поддержка будет. По мне - нарушение причинно-следственной связи.

2) Использование cgroup невероятно упрощает внутреннюю логику юнитов для запуска сервисов. СИИИИИИИИИИИИИИИИИИИИИИИИИИИИИИИИИЛЬНО.

Вот например юнит для bluetooth демона

[Unit]
Description=Bluetooth service
[Service]
Type=dbus
BusName=org.bluez
ExecStart=/usr/sbin/bluetoothd -n

[Install]
WantedBy=bluetooth.target

Alias=dbus-org.bluez.service

а теперь выполним одну весёлую комманду

khades@debian:/etc/init.d$ cat /etc/init.d/bluetooth |wc
201     584    4474

А теперь о мифах про systemd.

JOURNALD БИНАРНЫЕ ЛОГИ ХУЖЕ ЧЕМ В RSYSLOG

syslog - это стандарт отправки и регистрации сообщений о происходящих в системе событиях

rsyslog - программа для организации хранения этих сообщений, полученных по системной шине, реализованной в ядре linux (/dev/log)

journald - легковесный сервис для хранения и чтения логов с хранением их в памяти для ускорения процессов ввода\вывода во время загрузки с ОПЦИОНАЛЬНЫМ хранением бинарей на диске. НЕ ЛОМАЕТ rsyslog.

PID 1: ВСЁ УПАДЁТ ЕСЛИ УПАДЁТ SYSTEMD

1) Почему systemd должен упасть?

2) Ядро тоже падает, давайте все ненавидеть ядро

PID 1: СИСТЕМД МНОГО ВСЕГО В ОДНОМ ПРОЦЕССЕ ДЕРЖИТ И МНОГО НА СЕБЯ БЕРЁТ!!!!

1) Для изоляции запускаемых процессов и придуман CGROUP.

2) khades@debian:~$ ps aux |grep systemd root 284 0.0 0.1 297788 11032 ? Ss фев13 0:01 /lib/systemd/systemd-journald root 295 0.0 0.0 42944 1924 ? Ss фев13 0:00 /lib/systemd/systemd-udevd root 2448 0.0 0.0 36928 1636 ? Ss фев13 0:00 /lib/systemd/systemd-logind

ПОТЦЕРИНГ ЧТОТО ПОМЕНЯЕТ И ВСЁ СЛОМАЕТСЯ

Даа, и это сразу попадёт в стейбл дебиана. инфа 100%.

И последнее, касаемо непортируемости на другие ядра. В нашем случае глупо не использовать передовую технологию (CGROUP) ради совместимости с принципиально другой системой, учитывая то количество ништяков, которое оно нам даёт реализовать. Я вообще в далёком будущем представляю как на помойку выкидывают selinux, потому что домены безопасности реализуют на основе namespaces и cgroup. Ах мечты, мечты.

Но для покупки лицензионных программ, есть такое? Будет? Или это фантастика?

Сабж

cast Ttt

Вот решил жене показать, как оно раньше было. Но обломался.

Народ! Кто помнит как мышь настроить?

13 рублей, почтовые расходы вы берете на себя.

>>>

26 рублей

>>>

Lennart Poettering, сотрудник компании Red Hat, представил концепцию принципиально нового механизма управления инициализацией системы — systemd (system daemon), которая вобрала в себя достоинства классического System V init и более современных launchd (Mac OS X), SMF (Solaris) и Upstart (Ubuntu, Fedora), но при этом лишена многих их недостатков. В разработке этого проекта ему помогали сотрудники Red Hat, Novell, IBM, Intel и Nokia.

systemd опирается на современные linux-технологии: cgroups, AutoFS, D-Bus, и при этом совместим с исторически устоявшимися механизмами: init-скриптами, стандартными командами shutdown, poweroff и т.п. Предоставляемый systemd функционал позволяет заменить не только систему инициализации, но и ряд других подсистем, в частности, cron, (x)inetd, xdm/kdm/gdm/..., частично даже SELinux.

Основные идеи, использованные при создании systemd:

• Контроль над сокетами. Многие демоны, запускаемые при инициализации, взаимодействуют с другими демонами через unix domain и сетевые сокеты, и большинство существующих систем инициализации запускают демона-клиента только после того, как демон-сервер запустится и создаст сокет. Вместо этого, systemd создает сокеты, а затем запускает демонов, передавая им эти сокеты. Даже если демон-клиент запустится быстрее и начнет использовать сокет раньше сервера, ничего страшного не произойдет: его запрос будет буферизован и передан серверу, как только тот сможет его обработать. Такой подход уже используется в Mac OS X (launchd), позволяя этой ОС достигать впечатляющей скорости загрузки.

  Аналогичный принцип используется systemd и при запуске служб, использующих шину D-Bus.

  Кроме того, возможен автоматический запуск служб при обращении к заданным сокетам (см. ниже).

• Фоновое монтирование. Такие операции, как монтирование, проверка и активация квот файловых систем, занимают весьма значительную долю загрузочного времени. В большинстве современных систем они выполняются последовательно, до запуска всех демонов. systemd же предлагает монтировать не-жизненно-важные ФС только тогда, когда они кому-то понадобятся. Для этого используется механизм AutoFS. Например, многие служебные демоны вовсе не обязаны ждать, пока смонтируется огромный и к тому же зашифрованный /home.

  Разумеется, этот подход неприменим к /, /proc, /sys и т.п.

• Минимизация числа вспомогательных процессов. В настоящее время значительная часть работ по инициализации производится шелл-скриптами, что приводит к колоссальным времязатратам. В частности, Леннарт пишет:

  On my system the scripts in /etc/init.d call grep at least 77 times. awk is called 92 times, cut 23 and sed 74,

  при этом замечая, что почти каждый такой запуск влечет накладные расходы на поиск библиотек, подгрузку данных интернационализации (i18n) и т.п.

  В качестве альтернативы Леннарт предлагает предлагает переписать критичные участки на C, а также вынести часть функционала в самих демонов и в systemd. Сейчас для systemd уже готовы написанные на C подсистемы монтирования и установки имени хоста. До полной победы, отмечает Леннарт, работа предстоит огромная, но результат того стоит.

• Отслеживание процессов. В ныне используемых системах инициализации в принципе возможна такая ситуация, когда при неправильном форке процесс может «потеряться». Например, так может произойти с некорректно написанным CGI-приложением, и процесс останется работать даже после остановки веб-сервера.

  Для предотвращения таких ситуаций systemd использует интегрированный в ядро Linux механизм контрольных групп (cgroups). Если приложение не имеет доступа к псевдо-ФС, управляющей работой cgroups, то оно не может самостоятельно покинуть свою группу и «потеряться».

  Также к этой группе задач относится и автоматический перезапуск демонов, перенаправление их stdout/stderr на выбранные TTY или в системный журнал, регистрация всех запусков и остановок служб, и многое другое.

• Ограничение процессов. systemd предоставляет множество возможностей ограничить или расширить полномочия процессов, контролируя такие параметры, как uid, gid, umask, рабочий и корневой каталоги, класс и приоритет CPU и I/O, наличие доступа на чтение и запись к смонтированным файловым системам и отдельным каталогам и т.п. Также можно использовать возможности по ограничению ресурсов, предоставляемые cgroups.

Базовым элементом systemd являются модули (units), которые связаны между собой и имеют определенный тип. Каждый модуль может требовать для своей работы другие модули, конфликтовать с модулями, запускаться только после или до определенного модуля (директивы конфигурации Requires, Conflicts, Before, After, Wants). Из типов модулей определены:

• service — обычный демон, поддерживающий операции start, stop, restart, reload. Может быть представлен родным (native) файлом конфигурации systemd или System V init-скриптом.
• socket. При обращении к сокету генерируется событие, для которого можно настроить обработчик. Например, автоматически запускать определенные службы при обращении к заданному сокету. В этом отношении systemd похож на давно известный (x)inetd, однако при этом поддерживает unix domain сокеты и FIFO.
• device. Отметив нужные устройства в конфигурации udev, впоследствии можно использовать такие события, как появление и удаление устройства, в качестве событий systemd, назначив на них обработчики. Например, при появлении устройства bluetooth будет запущена соответствующая служба.
• mount. systemd контролирует все точки монтирования файловых систем. В целях обратной совместимости поддерживается сбор информации о точках монтирования из /etc/fstab.
• automount. Для помеченных таким образом точек монтирования, монтирование выполняется только при обращении к ним.
• target. Более гибкий аналог уровней исполнения (runlevels), используемых в System V init. Представляет собой группу служб, объединенных по функциональному назначению. Например, multi-user.target идентичен runlevel 5, а bluetooth.target приводит к инициализации подсистемы bluetooth.
• snapshot — во многом похож на target. Позволяет «запомнить» существующую конфигурацию units (запущенных служб, открытых сокетов, смонтированных ФС) с тем, чтобы в дальнейшем восстановить это состояние. Позволяет, например, перейти в emergency shell (сейчас это init 1), а затем полностью восстановить набор запущенных служб. Другой пример — выход системы из состояния suspend.

Надо заметить, что systemd отличается от SMF, во-первых, тем, что позволяет оперировать не только зависимостями между службами, но и событиями, например, «готовность устройства» или «обращение к сокету». Во-вторых, systemd использует более простой формат файлов конфигурации (.desktop aka .INI против XML в SMF).

От upstart же systemd отличается более высокой степенью параллелизации, и как следствие, более высокой скоростью загрузки. Например, если демон A требует для работы сокет, открытый демоном B, то upstart сначала запустит демона B, а затем демона A, в то время как systemd создаст сокет сам и запустит обоих демонов одновременно, что занимает примерно в два раза меньше времени. Используемый в upstart принцип, когда ключевыми событиями является лишь запуск и остановка демона, Леннарт и его коллеги считают изначально неэффективным.

Well, the point of the part about Upstart above was to show that the core design of Upstart is flawed, in our opinion. Starting completely from scratch suggests itself if the existing solution appears flawed in its core. However, note that we took a lot of inspiration from Upstart's code-base otherwise.

>>> Подробности

Помогите, пожалуйста. Знаю, похожие темы были, но у меня немного другой случай. Уже который день бьюсь с проблемой, поиски в гугле мало к чему привели. Есть веб-сервер, который видно из локалки, но не видно извне. Сервер не подключен через роутер, он сам раздает интернет. IP - динамический. ДНС получаю через no-ip. SSH и FTP работают, то есть через инет можно попасть на сам сервер, а вот на апач нельзя.

Файл хоста настроен так:

<VirtualHost *:80>
        ServerAdmin admin@vampir1510.no-ip.biz
        ServerName vampir1510.no-ip.biz
        ServerAlias vampir1510.no-ip.biz
        DocumentRoot /var/www/share
        <Directory /var/www/share>
                Options FollowSymLinks Indexes MultiViews
                AllowOverride all
                order allow,deny
                allow from all
        </Directory>
               
        AddType application/x-httpd-php .php .php3 .php4 .php5 .phtml
        AddType application/x-httpd-php-source .phps
</VirtualHost>

Пробовал добавлять NameVirtualHost *:80 в начало - безрезультатно.

И еще:

neon@server:/etc/apache2/sites-available$ sudo netstat -tunpl | grep 80
tcp6       0      0 :::80                   :::*                    LISTEN      19391/apache2
tcp6       0      0 :::5800                 :::*                    LISTEN      3858/vino-server
udp        0      0 10.176.64.82:48097      0.0.0.0:*                           15053/python

Я относительно недавно начал изучать Линукс, не бейте сильно, если что-то упустил)

Перемещено leave из general

Есть 2х мерный массив объектов (матрица)

MyClass[][] array = new MyClass[n][n];

Надо пройти ВСЕ возможные комбинации нулей и единиц в этом массиве. Лупами, без использования рекурсии. Каждую получившуюся комбинацию нужно иметь возможноть сравнить с имеющейся (здесь не дано). Знаю, что количество полученных комбинаций очень велико, 2^(n*n), но все же.

Язык java.

Собственно, вопрос скорее теоретического свойства.

Подписываюсь я на события в директории (nio2, практически по примеру http://docs.oracle.com/javase/tutorial/essential/io/notification.html), и вот такая беда: ни одного события ENTRY_MODIFY. Изменения файла приводит к выбрасыванию ENTRY_CREATE. Это нормальное поведение, или я что-то накосячил?

фс - ext4

подписываюсь:

try {
    path.register(watcher,
      ENTRY_CREATE,
      ENTRY_DELETE,
      ENTRY_MODIFY
    )
  } catch {
    case e:IOException =>
      log.debug("all fails with {}",e)
      context.stop(self)
  }

обработка акторами, но потерять не мог. кому интересно - код тут https://github.com/LastPossum/SAWS/blob/master/src/main/scala/PathWatcher.scala

Собственно у кого какие были истории успеха/неуспеха? Идти по профилю или податься в другие степи?

OpenNota - свободное веб-приложение для коллективного перевода текстов с одного языка на другой, сходное с notabenoid.com.

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

В списке TODO также находятся:

1. Закладки и комментарии
2. Словарь перевода
3. Поиск по переводам
4. Локализация
5. Блоги и форумы
6. Скачивание готовых переводов в форматах HTML и FB2
7. Управление с клавиатуры
8. Память перевода

и многое другое.

Приложение написано на CoffeeScript+haml+Go с использованием фреймворков AngularJS и Revel и базы данных MongoDB.

Репозиторий на GitHub: https://github.com/opennota/opennota