Установил Gentoo

В # locale всё POSIX, никаких ru_RU и подавно нет.

Собсна, откуда чистый Mozilla Firefox при первом запуске узнаёт что я из RU, предлагая мне в качестве закладок по-умолчанию поисковик Yandex, а не Google, социальную сеть VKontakte, а не Facebook, социальную сеть Odnoklassniki, а не MySpace?

Известно, откуда. Доколе!?

Я догадываюсь, по какой причине в Gentoo по-умолчанию nano: чтобы попросту избежать холиваров vim vs emacs (ведь всем известно что vim лучший азаза).

По-умолчанию установщик emerge -a vim предлагает установить 7 не нужных пакетов, но к счастью есть USE-флаг minimal, так что включив echo "app-editors/vim minimal" >> /etc/portage/package.use/vim таки установился один единственный vim. Ну и до кучи сделал его редактором по-умолчанию: eselect editor set /usr/bin/vi.

Теперь можно наконец забыть про nano, но не тут-то было. emerge -ac говорит что nano теперь orphan и больше никому не нужен, но при этом тут-же предупреждает что его удаление может сломать систему.

!!! 'app-editors/nano' (virtual/editor) is part of your system profile.
!!! Unmerging it may be damaging to your system.

Это конечно здорово, но тут прям какое-то деление на ноль. EDITOR/VISUAL=/usr/bin/vi, nano никем не используется, почему система по прежнему говорит что его нельзя безопасно удалить? Хоть и предлагает это сделать.

not-a-bug, но это следует пофиксить, однако по запросу «nano» в багтрекере gentoo такой проблемы не нашёл, но такая проблема и такой вопрос возник не у меня одного: http://www.gentoo.ru/node/23285

И кстати, теперь вспомнил за что так не люблю все эти дистрибутивы: у всех мейнтейнеров своё видение какие зависимости нужны к пакетам, какие нет.

К сожалению, Gentoo — это не про минимализм. Установка одного безобидного пакета приводит к дополнительной установке всякого мусора, которую не всегда можно разрулить USE-флагами, как в случае с minimal, но даже в этом случае USE-флаги не являются панацеей т.к. не все пакеты нужны в «minimal». В итоге что имеем, USE="-*", а дальше через package.use каждый пакет настраиваем руками, кхе-кхе.

Установил Gentoo, выбрал ветку [22] default/linux/amd64/17.0/no-multilib (stable) *, при запросе emerge gentoo-sources оно качает ядро 4.14, но я бы предпочёл использовать последнее ядро.

Допустим, при использовании стабильной ветки оно предлагает по-умолчанию стабильное ядро. Но можно же указать версию пакета! Однако emerge =sys-kernel/gentoo-sources-4.20.3 хочет чтобы я добавил эту строчку в «package.accept_keywords», мне это кажется не очень хорошим вариантом т.к. новые версии ядра выходят часто чтобы постоянно редактировать этот файл, и так достаточно того, что я указываю ему при установке какую версию хочу. Но оно в упор не хочет его ставить.

Попробовал переключиться на другую ветку [37] default/linux/amd64/17.1/no-multilib (dev), но резльтутата это не дало, по прежнему не могу тупо скачать последнюю версию ядра. Ещё он предлагает использовать опцию --autounmask-write, типа чтобы он сам дописывал в конфиг какую версию можно качать. Этот вариант тоже не по душе, т.к. что-то мне подсказывает, что за этим файлом в дальнейшем никто следить не собирается, и там наберётся огромный список пакетов, в том числе устаревших спустя N лет.

В общем как это сделать правильно? По-гентовски? Гугл не помог.

Здравствуйте мои маленькие любители авиационного спирта! Уже не за горами релиз дистрибутива для настоящих суровых мужиков, на данном этапе известно о нём немногое, но если заглянуть в git, то можно узнать вот что: https://crux.nu/gitweb/?p=ports/core.git;a=shortlog;h=refs/heads/3.5

# ports -d
Collection  Name           Port      Installed
core        bash           5.0-1     4.4.23-1
core        binutils       2.31.1-1  2.29.1-1
core        db             5.3.28-2  5.3.28-1
core        gcc            8.2.0-1   7.4.0-1
core        glibc          2.28-1    2.27-3
core        glibc-32       2.28-1    2.27-3
core        openssl        1.1.1a-1  1.0.2q-1
core        readline       8.0-1     7.0.5-1

С обновлением пакетов всё понятно.

Если провести сравнение 3.4 и 3.5, то пока ещё ничего небыло привнесено или удалено из core, но в планах уже известно, что pkg-config будет заменён на pkgconf, как это было сделано в Arch Linux. https://crux.nu/bugs/index.php?do=details&task_id=1667&tasks=all&...

Загрузчик lilo вынесут из core в opt, и это правильно, потому как UEFI шагает по планете: тому нужен только жыр32 раздел и CONFIG_EFI_STUB=y ядро. А так же: Intel to Remove Legacy BIOS Support from UEFI by 2020. Ощщем всё правильно сделали. Загрузчики не нужны.

firefox-bin уже обсудили.

На сегодня это пока все новости. Буду держать в курсе. 8-)

    firefox 63 will be the last firefox version released by me.
    Starting from firefox 64 I will replace firefox with the official binary build.
    
    This will have multiple advantages:
    We will avoid the endless buildtime horrorshow that has forced us to depend
    on stuff like rust, clang and starting with firefox 64: nodejs, which was my
    personal breaking point.
    
    List of notable obsolete dependencies include rust, clang and autoconf-2.13.

ребятам из CRUX надоело тащить на себе в меру (нет) упитанную лису, которая с возрастом всё жирнее и жирнее.

задумываюсь о том чтобы переходить на Gentoo, более монструозный комбайн по сравнению с CRUX, ведь CRUX не может жить вечно в таком виде, в каком его задумывали авторы, как в случае с firefox «обстоятельства так сложились»(с), в конце концов, сами авторы не вечны. а потом опять начнётся какая-нибудь свистопляска а-ля «versus systemd», которая в других дистрибутивах уже устаканилась лет дцать назад (к тому моменту). в этом смысле Gentoo жирный мамонт, который существует пару десятков лет, у Gentoo огромное коммунити и вытворять что хочу там попросту не дадут (наверное).

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

если у вас шина SATA-3 всё ещё 6Gbps?

В прошлом треде [Как взломать компьютер без адреса в сети?] мне указали на ошибки, что затея вобщем-то фейловая. Хотя изначально, вот прям в самом-самом начале, я планировал что будет виртуалка получать IP и сидеть в интернете, а другие виртуалки по соседству будут пускать различные сервисы, ну а хост-система вообще никак в этом деле не участвовать, тобишь даже локального доступа из какой-то виртуалки на хост быть не должно. Тогда хост выполняет роль «танка». Да.

В общем ладно. Вернёмся к тому с чего начали. Пусть хост сидит в интернете и сам тогда раздаёт интернет виртуалкам.

Остался открытым вопрос, как лучше форвардить трафик с хоста на виртуалки? Известно как, важнее знать как лучше. В бридже каждая виртуалка будет видиться как обычное устройство внутри локалки.

               ----------
              | Интернет |
               ----------
                   |
                   |
                --------
               |  ПеКа  | 192.168.0.1
                --------
                   |
                   | 192.168.0.0/24 br0
       ____________|_______________
      |            |               |
  ----------     ----------     ---------
 |          |   |          |   |         |
 |   ПеКа   |   |   ПеКа   |   |   KVM   |
 |          |   |          |   |         |
  ----------     ----------     ---------
                                    |
  192.168.0.2    192.168.0.3    192.168.0.4
                                    |
                                ----------
                               |          |
                               |    VM    |
                               |          |
                                ----------
                                192.168.0.5 tap0 master br0

Первый вариант

iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to 192.168.0.5:80

Когда мы тупо форвардим всё как есть со своего порта на порт нужного хоста. Работает на уровне ядра и всё круто.

Второй

iptables -t nat -A PREROUTING -p tcp --dport 1:65535 -j REDIRECT --to-ports 80

Форвардить весь трафик на 80 порт нашего же хоста, а у нас будет крутиться nginx который в зависимости от... будет сам форвардить сырой трафик далее к нужным виртуалкам. Работает на уровне пользователя, чуть помедленее, но например, на этом уровне можно настроить обработку SSL-сертификатов, чтобы это делал nginx, а далее к виртуалкам уже пропускал чистый трафик... Из этого метода можно извлечь свои плюшки, nginx может балансировать трафик и кучу всякого такого.

Третий

Ваш вариант, предложите как лучше форвардить трафик на виртуалки. Спасибо.

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

GNU/Linux, *BSD и другие системы становятся «целью в себе», и вместо того чтобы посвящать время MMORPG, люди отдают его жизни и творчеству в этой ОС.

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

А почитать пламенные обсуждения в чатах, на форумах, так разгорающиеся обсуждения на те или иные темы по яркости могут затмить не одно игровое сообщество.

Ну, признавайтесь, для кого линукс это просто развлечение? Пойду дальше с виртуалочками играться...

Картина для привлечения внимания: http://dump.bitcheese.net/files/vaxurut/scrot.png

И так, есть домашний ПК, есть провайдер, шнур с интернетом от которого идёт прямо в ПК. Наш ПК в сети. Однако захотелось сделать так, чтобы наш ПК небыл в сети, а в сети была _виртуальная машина_, которая уже затем раздаёт интернеты на наш ПК и другие умные устройства. Таким образом, наш ПК не имея адреса в сети, становится полностью неуязвимым. Поправьте, если ошибаюсь. А ошибаться я могу, ну вы же знаете, админы подкроватных локалхостов, куда уж нам...

В общем для реализации потребуется qemu и какой-нибудь дистрибутив по вкусу, я выбрал конечно CRUX.

Нужно ли объяснять процесс установки?

wget http://ftp.morpheus.net/pub/linux/crux/latest/iso/crux-3.4.iso
mount crux-3.4.iso /mnt/crux
dd if=/dev/zero of=crux.raw bs=1M count=1000
losetup /dev/loop0 crux.raw
fdisk /dev/loop0 # или fdisk crux.raw
# n
# enter
# enter
# enter
# w
mount /dev/loop0p1 /mnt/rootfs # или mount -o offset=$((512 * 2048)) crux.raw
mkdir -p /mnt/rootfs/var/lib/pkg
touch /mnt/rootfs/var/lib/pkg/db
for pkg in /mnt/crux/crux/core/*; do pkgadd --root /mnt/rootfs/ $pkg; done
echo "/dev/sda1 / ext4 defaults 0 1" >> /mnt/rootfs/etc/fstab

Усё. CRUX условно готов к работе в виртуальной машине, в общем-то дело за ядром, для полноты картины оставлю тоже это тут.

wget https://cdn.kernel.org/pub/linux/kernel/v4.x/linux-4.20.tar.xz
tar xf linux-4.20.tar.xz
cd linux-4.20
make defconfig
make -j$(nproc) all
env cp arch/x86/boot/bzImage /mnt/rootfs/boot/vmlinuz
env INSTALL_MOD_PATH=/mnt/rootfs make modules_install

sync # или umount /mnt/{crux,rootfs}

Можно запустить виртуальную машину с только что установленным CRUX, которая и будет нашим шлюзом в интернет.

qemu-system-x86_64 \
	-machine type=pc,accel=kvm \
	-cpu host \
	-boot order=c \
	-drive file=crux.raw,format=raw \
	-nic tap,mac=<Ваш MAC-адрес> \	# это будет WAN-порт
	-nic tap \			# это будет LAN-порт
	-kernel /mnt/rootfs/boot/vmlinuz -append "root=/dev/sda1"

Как видно из параметров, у виртуальной машины будет две сетевые карты, одна — клонирует мак-адрес вашей сетевой карты с провайдером, она же выполняет роль WAN-порта в роутере, вторая будет служить для раздачи интернетов, она же выполняет роль LAN-порта в роутере.

Напомню, что от интернетов сетевую карту на вашем ПК надо отключить, просто лишить её IP-адреса, оставив в режиме UP.

ip addr del xx.xx.xx.xx dev enp1s0u4h3l2p4a3q4t5b9d0n7m2x3 # лёня привет

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

# включили первый свич
ip link add name br0 type bridge
ip link set br0 up

# в один порт воткнули кабель провайдера
ip link set enp1s0 master br0
ip link set enp1s0 up

# в другой порт воткнули кабель от виртуалки
ip link set tap0 master br0
ip link set tap0 up

Таким элементарным образом настроено общение между кабелем провайдера и первой сетевой картой виртуальной машины, где вы указывали свой мак-адрес. Прямо сейчас, вы можете настроить интернет на виртуальной машине, так, как если бы его настраивали на обычном ПК, и этот интернет будет работать. Если у провайдера IPoE — просто dhcpcd enp0s3, если PPPoE, настраиваем на виртуалке PPPoE, всё как обычно в общем.

Если у вас какой-то другой интерфейс, куда приходит интернет, например это может быть не сетевая карта, а USB-модем, то соответственно в порт так называемого «свича» втыкаем кабель с этим интерфейсом, — ip link set usb0 master br0.

И ещё один свич, который будет связывать нас и второй интерфейс сетевой карты виртуальной машины, раздающий интернеты.

# включили второй свич
ip link add name br1 type bridge
ip link set br1 up

# в один порт воткнули кабель виртуальной машины раздающий интернеты
ip link set tap1 master br1
ip link set tap1 up

В другой порт «свича» пока ничего не «втыкаем», но опять же на этом этапе это уже может быть ваша вторая сетевая карта на ПК, которая например раздаёт интернеты дальше уже на реальный свич, и так далее. Но мы пока ограничимся только нашей хост-системой. Поэтому пока ничего.

На этом настройка ПК закончена, переходим к виртуальной машине. Собственно, там надо настроить интернеты на первом интерфейсе enp0s3, как это сделать — точно так же, как вы обычно настраиваете их на своём ПК. В случае IPoE, повторюсь, достаточно dhcpcd. Если интернеты настроены, о чём ping linux.org.ru радостно сообщает, теперь останется лишь настроить раздачу интернетов на вторую сетевую карту виртуальной машины.

Переходим к настройке виртуальной машины.

Поднимем интерфейс на второй сетевой карте, который будет обслуживать 192.168.0.0/24 подсеть и раздавать туда IP-адреса.

ip addr add 192.168.0.1/24 dev enp0s4 broadcast +
ip link set enp0s4 up

Установим DHCP в CRUX

prt-get depinst dhcp

Настроим DHCP

# cat > /etc/dhcpd.conf << EOF
authoritative;

default-lease-time	600;
max-lease-time		7200;

ddns-update-style	none;

subnet 192.168.0.0 netmask 255.255.255.0 {
  option domain-name "VirtualMachine";
  option domain-name-servers 8.8.8.8, 8.8.4.4;
  option routers 192.168.0.1;

  range 192.168.0.2 192.168.0.254;
}
EOF

Запустим DHCP

/etc/rc.d/dhcpd start

Ну и настроим раздачу интернетов.

echo 1 > /proc/sys/net/ipv4/ip_forward

iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -o enp0s3 -j MASQUERADE

На этом всё. И так...

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

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

br1 — теперь ваш доступ в интернет.

Сюда можно включить вторую реальную сетевую карту с реальным свичём, а можно подключиться самому.

dhcpcd br1

И вуа-ля! Мы в интернете через виртуальную машину, при этом наша хост-система недосягаема «из вне».

TL;DR

Возвращаясь к картинке http://dump.bitcheese.net/files/vaxurut/scrot.png, поясню что на ней. Слева направо: выхлоп красивого ifconfig на хост-системе. Далее окошечко с виртуальной машиной и чуть ниже SSH-подключение к ней же, с выхлопом ifconfig уже самой виртуалки. Далее тестируем подключение к br1, тестируем получение локального IP-адреса, тестируем подключение к интернету и что реально всё работает! Ну а в самом низу просто запуск виртуалки. Да.

Замечания и предложения приветствуются! Всем спасибо.

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

А потом втыкаешь видеокарту и enp1s0 становится enp2s0, и всё равно всё ломается.

Ну и. Ради чего? Всю жизнь жил с net.ifnames=0 в CONFIG_CMDLINE и дальше буду жить.

https://www.kernel.org/

у меня всё.

http://dump.bitcheese.net/files/jahonik/scrot.png

http://dump.bitcheese.net/files/xynokef/scrot.png

И так, друзья, шёл третий день как я развлекаюсь с виртуалками. Наверное, в 2077 году так будут называть кибер-девушек с низкой социальной ответственностью, но на сегодняшний день, к сожалению, это виртуальные машины KVM.

Во-первых, удалось с использованием бриджа построить локальную сеть, интерфейсу br0 присваивается 10.0.0.1/8, а когда запускается KVM, она автоматически поднимает интерфейс tap0, который цепляется к br0, затем отрабатывает ISC DHCP раздавая IP. Всё работает. Подробнее тут: Виртуалы не видят друг друга o_O

Во-вторых, удалось с использованием того же бриджа, без всяких пробросов PCI, пробросить MAC виртуальной машины на сетевую карту. Зачем это надо? В ПК подключён шнур провайдера, сетевая карта получает IP-адрес по маку и я в интернетах. Я хочу чтобы сетевая карта не получала IP адрес, а просто находилась в режиме UP, но когда я запускаю виртуалку с моим маком — виртуалка получала этот IP и находилась в интернете. Получается будто бы виртуалка сидит в танке. Действительно, что в таком случае способно грохнуть хост-систему? Наверное уже ничего, кроме физического воздействия, или очередного Spectre/Meltdown, но это ещё придётся и виртуалку взламывать, короче защита о-го-го.

Я не знаю, правильно ли я всё сделал, но делал это так:

# создаём бридж
ip link add name br0 type bridge
ip link set br0 up

# после запуска виртуалки c -nic tap включаем и tap0
ip link set tap0 address "мой мак"
ip link set tap0 master br0
ip link set tap0 up

# сетевая карта с провайдером
ip link set enp1s0 master br0
ip link set enp1s0 up

Я не знаю как, но это заработало, чёрт, я запустил qemu, в SeaBIOS набрал dhcp и увидел что по моему маку выдался мой внешний айпишник. О как.

Получив теперь «бессмертный хост», в котором взломанная (ключевое слово !если!) виртуалка просто перезапускается в три секунды... Надо что-то делать дальше.

Хочу:

1) Насоздавать кучу других виртуалок под каждый сервис в отдельности. Это ок.

2) Все эти виртуалки надо связать в единую локальную сеть ИИИ чтобы к этой сети могли так же подключаться другие устройства, а эти виртуалки выглядят как рядовые устройства в сети. Эту сеть надо вывести обратно на вторую физическую сетевую карту.

Что я от вас хочу услышать. Я хочу чтобы вы предложили мне свою идею для топологии сети. И всё. Я не архитектор, я макака с консолью, уж что правда то правда.

Стоит ли все реальные устройства объединять в сеть 192.168.0.0/16, а виртуалки держать отдельно в 10.0.0.0/8? Или лучше сделать чтобы все они были в одной подсети? Какие адреса и для чего красивше будет использовать? Как бы сделали вы? Поделитесь идеями.

Спасибо.

Запускаю две qemu kvm, я их пингую, они меня пингуют, они пингуют интернет, но внезапно, они не видят друг друга в рамках своей же локальной сети построенной на бридже. Может я что-то упустил...

Запускаем две KVM отличающиеся только именами интерфейсов.

for TAP in tap0 tap1; do

  qemu-system-x86_64 -bios OVMF.fd \
    -enable-kvm \
    -snapshot \
    -boot c \
    -drive file=CRUX.qemu-image.raw,format=raw \
    -nic tap,ifname=$TAP

done

Как положено qemu дёргает /etc/qemu-{ifup,ifdown}, содержания:

#!/bin/bash

NETWORK_BRIDGE="br0"
NETWORK_INTERFACE="$1"

/sbin/ip link set $NETWORK_INTERFACE master $NETWORK_BRIDGE
/sbin/ip link set $NETWORK_INTERFACE up

На хост системе в ifconfig виднеются два сетевых интерфейса, tap0 и tap1, без IP-адресов, но в режиме UP, будем считать что так быть и должно(?).

br0 это виртуальный сетевой интерфейс (бридж), который поднимается при запуске хост системы в /etc/rc.local

ip link add br0 type bridge
ip link set br0 up
ip addr add 10.0.0.1/8 dev br0 broadcast +

Которому, конечно, присваивается огроменная подсеть для моего подкроватного энтерпрайза уровня локалхост.

ISC DHCP раздаёт адреса в этой подсети.

subnet 10.0.0.0 netmask 255.0.0.0 {
  option domain-name "VirtualMachine";
  option domain-name-servers 10.0.0.1;
  option routers 10.0.0.1;

  range 10.0.0.2 10.255.255.254;
}

Простым запуском qemu без всяких параметров можно убедиться что оно работает, нажать Ctrl + B для захода в консоль SeaBIOS'а и выполнить dhcp, и убедиться что IP-адрес выдал именно наш DHCP, работающий на br0.

Ну и iptables, в том же /etc/rc.local, который всё это дело маршрутизирует.

WAN=enp2s0 # интерфейс с интернетами провайдера

iptables -P FORWARD DROP
iptables -t filter -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
iptables -t filter -A FORWARD -i br0 -j ACCEPT
iptables -t nat -A POSTROUTING -s 10.0.0.0/8 -o $WAN -j MASQUERADE

echo 1 > /proc/sys/net/ipv4/ip_forward

Так почему же виртуальные машины не видят друг друга, но видят интернет, и я вижу их с хост системы?

Первое знакомство с QEMU было в бородатые нулевые, когда запуск на одноядерном пентиуме приводил к невероятным тормозам. С тех пор как-то скептически относился к виртуализации, но теперь (уже 10 лет как, хех) добавили VT-d в консьюмерские процессоры и стало возможным работать с виртуализацией на аппаратном уровне.

Я впечатлён! Одна опция -snapshot чего стоит! Система работает в штатном режиме, но на самом деле находится в read-only, и никакие вообще изменения не сохраняются! Это же чудо! Это делает систему «unhackable». Теперь только успевай делать снапшоты данных, а в системе исправлять дыры и перезапускать пофикшенные виртуалки. Но знакомство с QEMU только началось и есть ряд вопросов.

1) MBR или GPT? UEFI или классический BIOS? Из коробки QEMU не умеет загружаться в UEFI, нужно отдельно скачивать OVMF прошивку. Стоит ли оно того? С одной стороны классический BIOS пережиток прошлого, вендоры вообще обещают зарезать legacy-режим в материнских платах к 2021 году, так что, чтобы в будущем образы систем стали легко переносимы, следует ли сразу ориентироваться на загрузку в UEFI? И забыть про lilo/syslinux?

2) Началась виртуализация головного мозга, так вот, возможно ли запустить qemu так, чтобы она напрямую общалась с устройством, а конкретно — сетевой картой? Хочу чтобы хост-система оставалась без IP-адреса, физический сетевой интерфейс был разве что в режиме UP, но при этом получение IP-адреса по маку осуществлялось прямиком на запущенную виртуалку, которая в дальнешем будет корневым шлюзом в сети. Возможно ли так пробросить сетевую карту в qemu?

И да, с разморозкой меня.

И где грань между «несколько компов в локалке» и «кластером»?

Я совсем запутался в этих терминах!

Навеяно топиком в Talks, изучаю рынок облачных решений, захожу на сайты, там большими буквами написано: создавайте VM, храните файлы, ещё чего-то там. Но при этом никакой конкретики что это, из чего состоит, для решения каких задач. Как компания, которая занимается ничем и производит ничего. А мне оно надо?

Ладно, хочу я своё облако сделать. Чтобы быть в тренде. Nextcloud, дак погодите-ка, это же просто файловый менеджер в браузере? Чего? И вокруг этого весь хайп? То, что ещё в нулевых называлось «файловым менеджером на php» теперь называется облаком?

Объясните пожалуйста, а то я совсем отстал от жизни!

И возвращаясь к первому вопросу. Какие задачи решают кластеры? Что нужно, чтобы из нескольких компов в локалке создать кластер? Хочу свой кластер сделать. Не знаю зачем, чтобы тоже в тренде быть. Я так понимаю, если я распараллелю nginx/php-fpm на два компьютера, чтобы там крутился «файловый менеджер на php» aka облако, это же не будет считаться кластером? Или будет?

И где мои таблетки?

Земля! (Ух ты!) Вот есть земля, так называемая планета, небольшой по вселенским меркам объект, но для биологического вида «человек» всё же обладающий внушительным размером. Земля имеет гравитацию. Да тут походу всё что имеет массу имеет и гравитацию. Вроде. Такой большой объект и не очень большая гравитация. Мы можем подпрыгнуть, например, гравитация конечно не даст далеко улететь, но всё же она небольшая. Кстати мне не нравится слово «большой» в отношении физической меры «гравитация», лучше давайте назову её «коэфициентом усиления». Коэфициент усиления гравитации на земле небольшой. Нооо, суть вопроса в чём, — почему коэфициент усиления именно такой? Кто решил, что «пусть для Хэ массы будет Уй коэфициент усиления»? Кто задал эту константу в рамках этой вселенной?

Вселенная! (Вау!) Существовала значит себе, не буду называть какой промежуток времени, ну невыносимо долго, так долго, что ей это надоело и она решила «пора чота менять». Это было ещё до «Большого взрыва», до, так называемого, «Старта существования вселенной», какой мы её знаем и наблюдаем сейчас. Но что менять? Какие процессы надо изменить во вселенной, чтобы сдвинуться с мёртвой точки? Вы понимаете, константы определены, но всё же «Большой взрыв» случился, из ничего, из NULL. А что случилось-то? Скопилась масса в одной точке во вселенной и сдетонировала? Но вы понимаете, что если изменить хоть одну константу, как то: банальнейшая скорость света, коэффициент усиления гравитации, ход времени; хоть на одну 0.00000~~~хау-ау-десу~~~00000-онную её изменить, эту константу, вселенная была бы уже абсолютно другой. Ну то есть, совсем другой. «Большого взрыва» могло вовсе не случиться. Галактики могли не сформироваться, так и оставшись кучкой мусорных объектов. Вселенная могла бы уже «изжить» себя и прекратить своё существования, просто.

Константы во вселенной определены и они такие какие есть, но а что если, они тоже подвержены некой эволюции? Ход времени — меняется, коэффициент усиления гравитации — увеличивается, свет — ускоряется. Вселенная была всегда, но так долго, и что-то случилось, она стала расширяться, дав старт «Большому взрыву». Что если изменение этих констант вселенной и послужило тому. Чтобы кучка мусора в одной точке вселенной разлетелась по всему пространству. А интересно, «Пространство» — тоже определённая константа, или оно так же эволюционирует и расширяется? А?

Такие дела.

Наивный Шома думает что ограничив комментирование он может снизить количество тупняка, но нет.
Предлагаю всем кто хочет отписаться в новости С новым 2019 годом! — писать в этот ИТТ in this thread тред.

Собсна, я то что и хотел написать.

С НОВЫМ 2019 ГОДОМ!

Прежде всего интересуют оригинальные песни, исполненные профессиональными музыкантами и записанными на студии. Читай, всё то, что можно считать обычной попсой, но только посвящённой компьютерной теме.

Ангина - Интернетный

Оля Полякова - Веб-камера

Земфира - Webgirl

Русский Размер - Пустой монитор

Ну а потом уже можно всякий трешак, хотя даже среди треша можно найти задушевную годноту.

Чёрный баннер

Кондитерское предприятие ищет толкового админа

Когда нет личной жизни, можно тратить время на чтение форума, постов 2х недельной давности, и выискивать, с кого бы поснимать скор «ни за что».

Оскорбление, маты, тупняк, зачём всё это, если можно поудалять никому не мешающие беседы участников, между прочим, не на слишком уж и отвлечённые темы. Топик про хлебобулочные изделия — обсуждаем хлебобулочные изделия. What's going wrong? Или у этого диктатора должны все по струнке ходить?