Нооо... Юних же один, не?)

линукс никакого отношения к юниксу не имеет. Вообще никакого

Не то что бы я был знатаком слаки, но разве там есть порты?

я же не сказал "второе"

линукс никакого отношения к юниксу не имеет. Вообще никакого

Ахахаха)) Я же говорил! Сча ортодоксы налетят!))

?

у меня всегда подгорает) от таких сравнений

Кто вспоминал ортодоксов? Hesiod и цербер а не самба!

FreeBSD foo.mng.zsttk 11.1-STABLE FreeBSD 11.1-STABLE #1 r329294M: Thu Feb 15 14:46:14 +07 2018 swp@foo.mng.zsttk:/usr/obj/home/.src/sys/foo-fbsd11-20170530 amd64. У меня программа валится при записи в "__thread char [0x2000]" буфер, который определён в моей библиотеке. Причём, если не линковать с -lpthread, то всё работает. Если выкинуть кусок из моей библиотеки с парсером json (на bison-е он) - тоже перестаёт падать... Если линковать библиотеку статиком - работает. Если уменьшить буфер до, например, 1000 байтов - тоже работает. Нет ли тут какого _известного_ bug-а (наверное в динамическом линкере)?

Я бы рекомендовал попробовать scan-build, есть в любом devel/llvm*.

Что такого может быть в программе, чтобы статическая линковка не давала SIGSEGV, а динамическая линковка давала? Это тест. Вывожу номер потока + адрес буфера + "ещё-там-уже не важно-что". Что имеем: [0] ectlno_msgbuf = 0x80062e940, ectlno_msgcurptr = 0x0. [6] ectlno_msgbuf = 0x800644940, ectlno_msgcurptr = 0x0. ectlno_msgbuf = 0x80062e140, ectlno_msgcurptr = 0x0 [3] ectlno_msgbuf = 0x800643140, ectlno_msgcurptr = 0x0. [9] ectlno_msgbuf = 0x800646140, ectlno_msgcurptr = 0x0. [1] ectlno_msgbuf = 0x800642140, ectlno_msgcurptr = 0x0. [4] ectlno_msgbuf = 0x800643940, ectlno_msgcurptr = 0x0. [8] ectlno_msgbuf = 0x800645940, ectlno_msgcurptr = 0x0. [2] ectlno_msgbuf = 0x800642940, ectlno_msgcurptr = 0x0. [7] ectlno_msgbuf = 0x800645140, ectlno_msgcurptr = 0x0. [5] ectlno_msgbuf = 0x800644140, ectlno_msgcurptr = 0x0. Поскольку потоки выполнятся начинают в произвольном порядке, то вывод выглядит не удобным для разглядывания. Если его упорядочить, то получим ectlno_msgbuf = 0x80062e140, ectlno_msgcurptr = 0x0 [0] ectlno_msgbuf = 0x80062e940, ectlno_msgcurptr = 0x0. [1] ectlno_msgbuf = 0x800642140, ectlno_msgcurptr = 0x0. [2] ectlno_msgbuf = 0x800642940, ectlno_msgcurptr = 0x0. [3] ectlno_msgbuf = 0x800643140, ectlno_msgcurptr = 0x0. [4] ectlno_msgbuf = 0x800643940, ectlno_msgcurptr = 0x0. [5] ectlno_msgbuf = 0x800644140, ectlno_msgcurptr = 0x0. [6] ectlno_msgbuf = 0x800644940, ectlno_msgcurptr = 0x0. [7] ectlno_msgbuf = 0x800645140, ectlno_msgcurptr = 0x0. [8] ectlno_msgbuf = 0x800645940, ectlno_msgcurptr = 0x0. [9] ectlno_msgbuf = 0x800646140, ectlno_msgcurptr = 0x0. Почему разница между __thread буфером в одном потоке и другом такая маленькая, ведь размер буфера в библиотеке задан в 0x2000 байтов?

Я не уверен, что __thread может быть больше указателя. Это же TLS, кто там память будет аллоцировать, дали слот в контрольном блоке потока и крутись как хочешь

совершенно точно были какие-то тонкости взаимодействия TLS и динамического линкера

совершенно точно были какие-то тонкости взаимодействия TLS и динамического линкера

+ TLS очень сильно зависит от платформы и от типа линковки. amd64?

Ребза, офтоп

Гдеб фрю надежно захостить ?

ферст вдс задрал ужо

vultr? :)

а что с ними не так?

нет по-моему никакого ограничения на tls данные... вот тестовая библиотека (в папке ./tls_test): [tls_test.h] #ifndef tls_test_h #define tls_test_h #define MAX_TLS_BUF 0x1000000 extern __thread char tls_buf[MAX_TLS_BUF]; #endif [tls_test.c] #include <tls_test.h> __thread char tls_buf[MAX_TLS_BUF] = ""; [Makefile] LIB= tls_test SHLIB_MAJOR= 1 INCS= tls_test.h SRCS= tls_test.c CFLAGS+= -I. LDADD+= .include <bsd.lib.mk> Warning: Object directory not changed from original /home/swp/c/foo-libs/c/__thread/tls_test cc -O2 -I. -march=native -MD -MF.depend.tls_test.o -MTtls_test.o -std=gnu99 -Qunused-arguments -c tls_test.c -o tls_test.o building static tls_test library ar -crD libtls_test.a NM='nm' NMFLAGS='' lorder tls_test.o | tsort -q ranlib -D libtls_test.a cc -fpic -DPIC -g -O2 -I. -march=native -MD -MF.depend.tls_test.pico -MTtls_test.pico -std=gnu99 -Qunused-arguments -c tls_test.c -o tls_test.pico building shared library libtls_test.so.1 cc -shared -Wl,-x -Wl,--fatal-warnings -Wl,--warn-shared-textrel -o libtls_test.so.1.full -Wl,-soname,libtls_test.so.1 NM='nm' NMFLAGS='' lorder tls_test.pico | tsort -q -lm -lpthread objcopy —only-keep-debug libtls_test.so.1.full libtls_test.so.1.debug objcopy —strip-debug —add-gnu-debuglink=libtls_test.so.1.debug libtls_test.so.1.full libtls_test.so.1 вот тестовая программа, которая линкуется с этой библиотекой (это уже папка уровнем выше): [tls.c] #include <stdlib.h> #include <stdio.h> #include <string.h> #include <pthread.h> #include <unistd.h> #include <tls_test.h> #define NTID 10 struct thrctl { pthread_t tid; int tno; }; void * test(void *p) { struct thrctl *tc; tc = (struct thrctl *)p; printf("[%d] tls_buf = %p.\n", tc->tno, tls_buf); memset(tls_buf, 0, sizeof tls_buf); sleep(1); return NULL; } int main() { static struct thrctl tc[NTID]; for (int i = 0; i < NTID; i++) { tc[i].tno = i; pthread_create(&tc[i].tid, NULL, test, tc + i); } printf("tls_buf = %p.\n", tls_buf); memset(tls_buf, 0, sizeof tls_buf); for (int i = 0; i < NTID; i++) pthread_join(tc[i].tid, NULL); return 0; } [Makefile] PROG= tls CFLAGS+= -I. -Itls_test LDFLAGS+= -Ltls_test LDADD+= -ltls_test -lpthread MK_MAN= no run : ${PROG} .PHONY /usr/bin/env LD_LIBRARY_PATH=tls_test ./${PROG} .include <bsd.prog.mk> Warning: Object directory not changed from original /home/swp/c/foo-libs/c/__thread cc -O2 -I. -Itls_test -march=native -g -MD -MF.depend.tls.o -MTtls.o -std=gnu99 -Qunused-arguments -c tls.c -o tls.o cc -O2 -I. -Itls_test -march=native -g -std=gnu99 -Qunused-arguments -Ltls_test -o tls.full tls.o -ltls_test -lm -lpthread objcopy —only-keep-debug tls.full tls.debug objcopy —strip-debug —add-gnu-debuglink=tls.debug tls.full tls make run /usr/bin/env LD_LIBRARY_PATH=tls_test ./tls [1] tls_buf = 0x803803130. [0] tls_buf = 0x802801130. [2] tls_buf = 0x804c04130. [3] tls_buf = 0x805c06130. [4] tls_buf = 0x807001130. [5] tls_buf = 0x808003130. [6] tls_buf = 0x809005130. [7] tls_buf = 0x80a007130. [8] tls_buf = 0x80b009130. tls_buf = 0x80121c130. [9] tls_buf = 0x80c00b130. т.е. ничего не упало, размеры огромные, всё замечательно заполнилось нулями... ???

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

Руководство жмется на дедик, а я вынужден мытарится

А что не так-то? Или просто надоело?

первая линия сапорта убивает

и в целом эта прослойка минус концепции Хостинга

Дедик, и нема проблем

Гдеб фрю надежно захостить ?

king-servers.com

ihor.ru

Hetzner Cloud

ферст вдс задрал ужо

А что именно с фрей у них не так, можно поподробней?

А что именно с фрей у них не так, можно поподробней?

вообще да, проблемы там не с фрей: а с саппортом конкретно)

или в хетзнере дедик на аукционе забрать как вариант

не подскажете как запустить архивацию tar с возможностью отжирать 50% CPU? а то бекапы большие стали и сайт вешается во время бекапа

man rctl, man login.conf

Гдеб фрю надежно захостить ?

У меня ihor. Только их образами не пользуйся они кривые. Ставь с isoшек

поправили уже фряшный образ ))

Это о котором "поправили" речь? Сначала у них хватило ума STABLE ставить, потом система не грузилась после freebsd-update. Это при том что я не чаще раза в год их образы пробую на новых виртуалках, а сколько потенциальных косяков там ещё... Вдобавок разбивка без свопа. Люди явно не умеют, нафик такое

вспоминайте чего там ещё, передам

Это о котором "поправили" речь? Сначала у них хватило ума STABLE ставить, потом система не грузилась после freebsd-update. Это при том что я не чаще раза в год их образы пробую на новых виртуалках, а сколько потенциальных косяков там ещё... Вдобавок разбивка без свопа. Люди явно не умеют, нафик такое

файловая не ресайзилась после установки

о. на это ещё не наступал

да так-то я им и сам в тп пишу. только stable они меняли на релиз около года, и на проблему с загрузкой, сейчас посмотрел, тоже какую-то ерунду отписали

передай лучше им чтобы хотя бы чуть-чуть тестировали свой образ. с pkg install ченить, freebsd-update, вот этим всем

Ок, сенкс

А что есть вместо cu в портах? Что-то у меня на стрекозе cu с u3g не дружит…

вообще да, проблемы там не с фрей: а с саппортом конкретно)

В точку

а как в линуксах заставить себя less вести себя как у нас

т.е. после выхода содержимое остается на экране

Ну и проблемы случаются тоже

alt screen терминала не юзать то блишь

Плюс у них появился vpu

Инсталятор кашляет на параметры сети vpu

У них забито

Я продавливаю дедик на работе, ибо заебало

Свое добро на выделеном держу, но вот до начальствующих сложно достучаться

а как в линуксах заставить себя less вести себя как у нас

less -X

гм, помогло, спасибо, но по описанию - пушка по воробьям...

Приветствую, здесь ОС freebsd?

Приветствую, здесь ОС freebsd?

Нет, это канал по аниме

Как пропатчить KDE?

ERROR: S client not available

под аниме?

Win10

Легче всего на MacOS и Ubuntu. Аналоги есть, но можно запускать и windows-программы с помощью wine

Ещё года 4 поддержки

Куда бежать то

Matlab/mathematica под линуксы были

Вроде

везде где вы умеете

Примерно одинаково

Странно что никто не предложил написать свой автокад

OpenCAD

Есть же

Ой. Я прст не в теме.

Draftsign

Не совсем опен

Но мультиплатформенный

А потом кватру и визуалцэпп

Не надо просто так бегать с ос на ос

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

в таких вещах обычно проблема в либах и вот этом всём

Ос берется под задачи

Ну в линукс хелпе точно

Не суть

Аналоги фотошопа: krita, gimp > интересуют gpl Другие лицензии не рассматриваете?

Всё дело в том, что ты вообще не отличишь BSD от линя. У тебя задача стоит такая, что и там и там софт один и тот же.

Аналог P-Cad'а: KiCad

обратись к поддержке за не шиндоус версиями