Re: Re[2]: Репрессии в России. Арест Дмитрия Богатова.

2017-06-10 Пенетрантность Sergey Kirpichev 
2017-05-08 15:45 GMT+03:00 Egor Klim :
> Я может действительно отстал уже от темы, но есть готовый/принятый 
> законопроект?
> (напоминаю, что внести законопроект на рассмотрение и принять его это разные 
> вещи
> ибо по закону даже самый бредовый проект вносят на рассмотрение в любом
> случае, но это ещё ни чего не значит)

UPD

Ну вот ваш проект и до Госдуры уже доехал:
http://asozd.duma.gov.ru/main.nsf/%28Spravka%29?OpenAgent=195446-7

(Теоретически, "бредовые" законопроекты - на рассмотрение выноситься
не должны.  Для того всякие "согласования" и прочие "профильные комитеты".)

Даже на рассмотрение проект поступил 8-го (Богатова арестовали
аккурат до этой даты)...

Re: Репрессии в России. Арест Дмитрия Богатова.

2017-05-23 Пенетрантность Sergey Kirpichev 
2017-05-19 17:32 GMT+03:00 artiom :
> 07.05.2017 23:13, Sergey B Kirpichev пишет:
>> On Sun, May 07, 2017 at 11:04:49PM +0300, Dmitry E. Oboukhov wrote:
 Было бы обвинение по уголовщине - наверно, текст на debian/press
 был бы другим.  Но обвинение - по политической статье.
>>> у нас нет разделения политических и неполитических статей в УК.
>> Дык и у Гитлера - тоже не было.
>
> Справедливости ради: было. Как и разделение полиций. Уголовными
> преступлениями занималась КриПо, политическими - ГесТаПо.
>
> И даже несмотря на то, что они были в ЗиПо объединены, они занимались
> своими делами.

Дык и Глеб Жеглов карманников не сажал.  Это что-ж получается,
карманники в СССР по какому-то отдельному, неизвестному науке УК жили?

Re: Репрессии в России. Арест Дмитрия Богатова.

2017-05-15 Пенетрантность Sergey Kirpichev 
On May 15, 2017 8:08 AM, "Dmitry E. Oboukhov"  wrote:
> >> первое письмо этого треда
>
> > А что, подтверждения ваших слов про "активистов" таки не воспоследует?
>
> вон Герасев же пришел и подтвердил, так и написал "инициировал я"
>
> что еще нужно?

Ну пусть, как минимум, хоть подтвердит кто начал это в private
и что он "активист".

Re: Репрессии в России. Арест Дмитрия Богатова.

2017-05-07 Пенетрантность Sergey Kirpichev 
2017-05-07 16:43 GMT+03:00 Геннадий Ковалёв :
> Неудачников, которые скидывают на власть свои
> собственные заблуждения, таким образом переубедить не получится.

Извиняюсь, вы имеете в виду кого-то конкретного, или мажете известной
субстанцией всех разработчиков Debian сразу, чтоб два раза не вставать?

> Обвиняя других в пропаганде они видят как раз свою силу в том, чтобы 
> агрессивно
> навязать своё мнение любыми средствами. Если надо идти по головам - пойдут.

Т.е. это они "по головам" тут шли, назвав прямым текстом Дмитрия Богатова
педофилом и убийцей, забежав даже впереди государственного обвинителя?

> Главное почувствовать свою крутизну. Хоть так, раз в делах не получается.

Можно полюбоваться на ваши дела для Debian, для начала?

Re: systemd (sysvinit осиротел, галактико опасносте!)

2016-07-01 Пенетрантность Sergey Kirpichev 
On Jun 30, 2016 4:18 PM, "Dmitrii Kashin"  wrote:
> > Увы, это говорит о том, что кто-то другой наплевал на багрепорты, причем 
> давно.
>
> Интересное замечание с учётом того, что авторы systemd тупо закрывают
> баги, которые им не нравятся. Это, по-вашему, называется "не забивать на
> багрепорты?

Речь шла о мейнтейнерах systemd в Debian.  Если у вас есть аргументы в
пользу таких "тупых закрытий" - баги просто надо открывать обратно, для этого
никаких специальных прав в проекте не надо.  Только желание делать работу.

А телепатически о вашем важном мнении просто никто не узнает
от слова совсем.  Такие дела.

> >> > Баги, висящие годами - это, увы, про sysvinit.
> >>
> >> Ну так надо работать, а не брюзжать в debian-russian о том, как всё
> >> плохо.
> >
> > И что, вы уже не брюзжите и пошли предложить свою помощь в RFA баг?
>
> Да, и уже включаюсь в работу.

Будем посмотреть.  Приятно что я хоть кого-то сподвиг.

Но было бы больше надежды, если б вы ранее были замечены
в работе над пакетами Debian.

Re: systemd (sysvinit осиротел, галактико опасносте!)

2016-03-02 Пенетрантность Sergey Kirpichev 
2016-03-02 12:08 GMT+03:00 Dmitry E. Oboukhov :
> первые и вторые не составят значимого сопротивления проталкивания УГ
> а у последним дешевле будет перейти на Gentoo, а если УГ дотолкают до
> него, то на LFS, либо появится форк.

Так всю дорогу и собираетесь переходить, пока другие гадят
в хорошие вещи?

LSI MegaRAID SAS 8208ELP в Debian

2016-02-07 Пенетрантность Sergey Kirpichev 
На всякий случай попробую поспрошать здесь.

Может кто-то из уважаемых имеет счастье иметь этот контроллер
в Debian, да еще в работоспособном виде?

# lspci |grep SAS
03:00.0 SCSI storage controller: LSI Logic / Symbios Logic MegaRAID SAS 
8208ELP/8208ELP (rev 08)

Задачи:
1) заставить его отдавать голые диски в систему (в наличии
при ем 3 шт. SAS разных размеров и разной степени убитости).
2) побить диски на разделы, сделать рейд средствами системы (md).
3) грузиться потом с этого самого контроллера.

C 1-2) худо-бедно получилось справиться, подсунув PCI ID
драйверу mptsas при инсталляции Debian Wheezy (см. напр.
http://forum.univention.de/viewtopic.php?f=48=1406
(В ядре из Jessie, вроде, этот idшник уже есть в драйвере.)
Загрузчик поставил на первый диск (sda), там же раздел для /boot,
далее на всех трех дисках выделил одинаковые разделы и
сделал raid5 массив.

А вот с 3) пока выяснилось следующее: контроллер позволяет
в своем биос пометить загрузочным только созданный там
райд-массив: в частности, raid0 из отдельного диска.  Именно
последний вариант я выбрал, сделав его из sda.

Система загружается, видит диски и разделы на них, за
исключением разделов на том самом первом диске.  Соответственно,
программный raid5 сразу разваливается.  Помимо дисков и созданных
мной mdadm массивов - виден также /dev/md127 (metadata:ddf), видимо
это то, что добавлено через BIOS контроллера.  Если сказать
mdadm --stop /dev/md127 && partprobe /dev/sda - появляются созданные
ранее разделы на первом диске, доступные для записи и после добавления
руками /dev/sda5 в развалившийся ранее raid5 массив - начинается
синхронизация данных на него (покуда массив не разваливается из-за
проблем с уже другим диском).

Подозреваю, что если сказать ядру md.ddf=0 - оно не будет стартовать
/dev/md127.  Будет ли этого достаточно, чтобы после загрузки корректно
определялись _все_ разделы и можно было обновлять загрузчик на /dev/sda
без риска повредить метаданные, что добавил контроллер?

PS: В аттаче прикрепил вывод mdadm с созданных массивов (уже после
убития raid5, увы, покуда еще там что-то шевелилось), --examine с sda.
$ sudo mdadm --detail /dev/md0
/dev/md0:
Version : 0.90
  Creation Time : Fri Feb  5 11:46:13 2016
 Raid Level : raid1
 Array Size : 248896 (243.10 MiB 254.87 MB)
  Used Dev Size : 248896 (243.10 MiB 254.87 MB)
   Raid Devices : 2
  Total Devices : 2
Preferred Minor : 0
Persistence : Superblock is persistent

Update Time : Fri Feb  5 22:15:29 2016
  State : clean 
 Active Devices : 2
Working Devices : 2
 Failed Devices : 0
  Spare Devices : 0

   UUID : 80bd2915:f9f84736:2e3043bf:80ad74ee (local to host debian)
 Events : 0.21

Number   Major   Minor   RaidDevice State
   0   8   170  active sync   /dev/sdb1
   1   8   331  active sync   /dev/sdc1

$ sudo mdadm --detail /dev/md1
/dev/md1:
Version : 1.2
  Creation Time : Fri Feb  5 11:47:01 2016
 Raid Level : raid5
 Array Size : 285988864 (272.74 GiB 292.85 GB)
  Used Dev Size : 142994432 (136.37 GiB 146.43 GB)
   Raid Devices : 3
  Total Devices : 3
Persistence : Superblock is persistent

Update Time : Fri Feb  5 23:59:24 2016
  State : clean, FAILED 
 Active Devices : 1
Working Devices : 2
 Failed Devices : 1
  Spare Devices : 1

 Layout : left-symmetric
 Chunk Size : 512K

   Name : debian:1  (local to host debian)
   UUID : 4b854156:7a4d61e6:aba2c6bc:836bc8c5
 Events : 2080

Number   Major   Minor   RaidDevice State
   0   000  removed
   1   001  removed
   2   8   372  active sync   /dev/sdc5

   1   8   21-  faulty spare   /dev/sdb5
   3   85-  spare   /dev/sda5


$ sudo mdadm --examine /dev/sda
/dev/sda:
  Magic : de11de11
Version : 01.00.00
Controller GUID : 4C534920:20202020::::
  (LSI )
 Container GUID : 4C534920:20202020:1055:::1424
  (LSI  01/01/80 03:00:00)
Seq : 000f
  Redundant hdr : yes
  Virtual Disks : 1

  VD GUID[0] : 4C534920:20202020:1055::43E64F20:0A28
  (LSI  02/05/16 22:16:48)
 unit[0] : 0
state[0] : Optimal, Consistent
   init state[0] : Not Initialised
   access[0] : Read/Write
 Name[0] : 
 Raid Devices[0] : 1 (0)
   Chunk Size[0] : 128 sectors
   Raid Level[0] : RAID0
  Device Size[0] : 438475776
   Array Size[0] : 438475776

 Physical Disks : 1
  NumberRefNo  Size   Device  Type/State
 0998e4942  438475776K /dev/sdaactive/Online


$ uname -a
Linux debian 3.2.0-4-amd64 #1 SMP Debian 3.2.73-2+deb7u2 x86_64 GNU/Linux

$ sudo mdadm --version
mdadm - v3.2.5 - 18th May 2012

$ sudo smartctl -a /dev/sdb
smartctl 5.41

Re: и об облаках

2014-03-03 Пенетрантность Sergey Kirpichev 
On Mon, Mar 03, 2014 at 12:22:56PM +0400, Artem Chuprina wrote:
 Два направления.  С
 одной стороны, наметившееся лицензионное пуританство, начинающее
 фактически работать против свободы (я не буду сейчас вступать в
 подробную дискуссию с поиском фактов - у меня нет для этого ресурсов, и
 я не навязываю никому своего личного мнения)

Факты были бы полезны, чтобы просто понять о чем идет речь.

 а с другой - постепенное
 огномление системы, начиная чуть ли не с ядра.

 Конкретно о systemd: не то чтобы я был против _идеи_ systemd.  А вот
 реализация меня, ой, стремает.

Ну, русскоязычные DD молчат в тряпочку - видимо они не против
решения TC и все идет как надо.  Да, грустно.  Оказывается,
не я один подумываю бросить дебиан.


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140303092831.gc26...@darkstar.order.hcn-strela.ru

Re: и об облаках (systemd)

2014-03-03 Пенетрантность Sergey Kirpichev 
On Mon, Mar 03, 2014 at 06:33:13PM +0400, Иван Лох wrote:
 Инициализация сервера требует надежности. А уж как она будет обеспечена:
 каждый раз некриворукими админом и майнтейнером дистрибутива или раз и
 навсегда верификацией солвера — разницы нет.

Полноте)  Там слов-то таких, поди, не знают.  В лучших
традициях Linux-kernel hackers (для примера, вот [1]).

Впрочем, с удовольствием посмотрю на блок-схемки, описывающие
алгоритм(ы?) работы systemd.  Их есть?  В документации не нашел
ничего даже отдаленно напоминающее подобное.

  [1] http://habrahabr.ru/post/108629/


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140303152038.gb32...@darkstar.order.hcn-strela.ru

Re: Программирование научных программ на C.

2014-02-08 Пенетрантность Sergey Kirpichev 
On Sat, Feb 08, 2014 at 07:43:34PM +0400, Dmitrii Kashin wrote:
 Обычно я, получив её, сажусь и выписываю
 каждый член ручками, и долго-долго занимаюсь его упрощением.

Ну что тут можно сказать.  Если вы не понимаете, что в
этом есть нечто неправильное, то объяснять далее - бесполезно...

 Так что численный метод для каждой новой задачи строится вручную, и
 никаких других путей я не вижу.

В ручную - можно по-разному.  Можно на бумашке карандашиком,
а можно наконец узнать о существовании современных CAS.

 Ну, учитывая, что Python славится своей нерасторопностью (хотя может я
 неправ, fixme), у меня есть подозрения, что проблемы с
 производительностью всё же будут.

Да, покуда вы не научитесь использовать эффективные алгоритмы.  Разруха - 
она помним где? ;)

 Ну, про Julia я слышу впервые. Опять же, связка C++ и LLVM вызывает
 недоверие. В википедии употреблена фраза sophisticated types system, я
 вот сижу и думаю, это хорошо или плохо?

По википедии знакомиться с чем-либо - не хорошо и не плохо.  Это глупо.

C++ там нету)
sk@darkstar:~/src/julia $ find . -name '*.c'|wc -l
64
sk@darkstar:~/src/julia $ find . -name '*.C' -o -name '*.cpp'|wc -l
8

 В общем, проект пока молодой

Это - да.

  Если не знаком никакой - есть повод выучить.

 Ну, на Perl, Bash и Zsh я бы не стал писать таких вещей. Я чётко ощущаю,
 что эти языки явно не для научных целей предназначены.

Из перечисленного - ничего кроме Perl и не попадает в
озвученную категорию.  Bash/Zsh - просто DSL.  Да и перл...


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20140208171547.ga28...@darkstar.order.hcn-strela.ru