XLibre 25.0 — первый выпуск форка X.Org Server

ты с лёгкостью можешь выбрать другой где нужная функциональность имплементирована

Пха-ха-ха-ха! Из полутора полуфункциональных композиторов выбирать?

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

То есть по сути wayland это просто разводка. Сначала сломаем, а потом или заставим самим чинить или пусть платят.

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

это тебя кидает, я не хаяла код rsync’а почём зря.

Ты сперва утверждала что «это школотроны вроде тебя таким могли заниматься, но они тогда ещё не родились», а потом «и что же, rsync не работает», как только узнала, что это твоя любивая священная корова. Твои идеалы гроша ломаного не стоят, если твой позвоночник гнется настолько легко.

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

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

так оно и есть. причём «пусть платят» - это конечная станция всего этого паровоза, которым красношапка пытается тянуть опенсорц в сторону зависимости от копрорастов.

ну так никто и не занимался таким. это тебя от незнания сишечки крючит. учись, и станет легче.

rsync прекрасно работает, проблем с ним нет. проблемы пока лишь в твоей голове.

ну так никто и не занимался таким. это тебя от незнания сишечки крючит.

Опять бла-бла-бла. Ты нейросеть что ли?

rsync прекрасно работает, проблем с ним нет.

Это же типичная мантра быдлокодеров, лол.

нет. просто мне неинтересно общение со школотроном, который в своём неосиляторстве почему-то обвиняет то какой-то опенсорцный код, то даже сишные стандарты. это уныло и я не хочу тратить время.

нет. просто мне неинтересно общение со школотроном, который в своём неосиляторстве почему-то обвиняет то какой-то опенсорцный код, то даже сишные стандарты. это уныло и я не хочу тратить время.

Ты просто не осилила сишку, чтобы понимать, почему int на одной платформе может быть 16bit, а на другой – 32bit. И это будет проблемой. Поэтому люди придумали stdint.h.

Бугога. Почему каждый раз выясняется, что все великие сишники лора не знают си?

С этой клоунессой то же самое: спрашиваешь, в чем выражается ухудшение кодовой базы - в ответ пространное блеяние о том, что собеседник ламер. Факты? Подтверждения словам? Не, не слышала.

Зато гонора и апломба на десятерых.

Ты на полном серьёзе? Не, не буду искать. Одно дело поговорить, другое дело непойми с чего броситься в актах разбираться. Не веришь мне? Да и ладно. Я это заметил в своё время, с тобой поделился. Всё. За доказательствами в соответствующие органы :)

У мужика на улице выпал кошелек, я его подобрал и стал бенефициаром.

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

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

Фантазии какие-то. Вот тебе два события:

1. Чувак лишился кошелька
2. Я его приобрел

Делает ли это меня мировой закулисой? Кажется нет.

нет, просто у школотронов богатая фантазия, но очень мало мозгов. я не смогу тебе ничего пояснить, пока не подрастёшь и не появятся мозги.

нет, просто у школотронов богатая фантазия, но очень мало мозгов. я не смогу тебе ничего пояснить, пока не подрастёшь и не появятся мозги.

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

Фантазии какие-то. Вот тебе два события:

Не фантазии, а иллюстрация к твоему некорректному примеру.

Уважаемый,
каждый ламер использует комп. Но не каждый, использующий комп - ламер.
В каждой «теории заговора» есть бенефициар. Но не каждый бенефициар - заговорщик.

Делает ли это меня мировой закулисой? Кажется нет.

Конечно, не делает.

я не смогу тебе ничего пояснить

Потому что конструктивных аргументов у тебя нет, одни лишь чувственные ощущения НЕПРИЯТНОГО на фоне диссонанса с синдромом утенка и «раньше было лучше».

Сходи лучше свой хомяк почини, у тебя верстка на странице поехала. Позорище.

В каждой «теории заговора» есть бенефициар. Но не каждый бенефициар - заговорщик.

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

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

А почему это должно быть ловушкой?

LMAO

Главное, рот не порвать

Приведи список платформ где rsync ломается из за этого. Обычно подразумевается что любой UNIX-софт требует int равным как минимум 32 битам.

Приведи список платформ где rsync ломается из за этого.

Ваще хз, суть-то не в этом. Разговор шел про то, что отрасль улучшается, а не наоборот.

Обычно подразумевается что любой UNIX-софт требует int равным как минимум 32 битам.

int 16 бит встречается на PDP-11, но там rsync еще никто не компилировал :).
А в свое время еще в 80-х годах было правило, если говорить о целых:
8 бит - char
16 бит - short int
32 бит - long int

Это в свое время без всяких ухищрений и кучи модных стандартов позволяло не иметь проблем с размерами данных. Правда, кто бы придерживался этого….

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

Если раньше можно было написать:

char line[100];
gets(line);

let mut line = String::new();
let stdin = io::stdin();
stdin.lock().read_line(&mut line).unwrap();

Если раньше отрисовка треугольника это вызов glBegin + glVertex. То теперь отрисовка треугольника занимает 2 000 строк минимум с Vulkan.

Если раньше добавялил контролы на форму и таким образом делали GUI, то теперь его долго и нудно хардкодят через мозговыносящие привязки GTK к Rust.

Большая часть тех кто не использует KDE используют gnome. Там уже давно сессия Wayland приоритетная.

Если раньше можно было написать

gets не проверяет границы, лол. У тебя тут RCE прячется.

Если раньше добавялил контролы на форму и таким образом делали GUI, то теперь его долго и нудно хардкодят через мозговыносящие привязки GTK к Rust.

Не, лялексового десктопа улучшения не касаются. Он как раз катится в какой-то ад.

А в свое время еще в 80-х годах было правило, если говорить о целых:

MSVC так и работает все еще: https://godbolt.org/z/dzr9Konq4

gets не проверяет границы, лол. У тебя тут RCE прячется.

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

Вообще исправляется проблема без изменения кода, добавлением bound-checkера в компилятор.

Не, лялексового десктопа улучшения не касаются. Он как раз катится в какой-то ад.

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

Для тебя открытие что типы, передаваемые по сети, должны быть четко фиксированы, чтобы протокол гарантированно работал на любой архитектуре? Если да, то у меня плохие новости – ты быдлокодер.

А где вообще есть код, который корректно извлекает биты из элементов массива char с данными переданными по сети? Например, каким-нибудь макросом, который умеет работать как с 8-бит, так и с 16-бит (да и вообще с любыми другими допустимыми размерами)?

который корректно извлекает биты из элементов массива char с данными переданными по сети

8 битный массив char можно читать напрямую, ничего к этому сверху не требуется.

Например, каким-нибудь макросом, который умеет работать как с 8-бит, так и с 16-бит (да и вообще с любыми другими допустимыми размерами)?

Если нужно прочесть uint16_t, то нужно сделать

char net_char_array[100];
socket_read_to(net_char_array[); 
uint16_t val = ntohs(*(const uint16_t *)net_char_array);

Но в правильном коде передаваемый по сети char нельзя так читать/писать, потому что код, может, компилируется на платформе, где в char - 16 бит.

Такой платформы не существует, верней она скорее всего есть, просто общий код для нее будет бесполезен, именно поэтому скоро в стандарте зафиксируют что char это 8 битный байт: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3477r0.html

Но при написании кода можно забыть о таком. Если кто то захочет иметь нормальный софт на такой платформе, то напишет компилятор который преобразует операции над char в операции над минимальной единицей uint16_t.

Так же, как сейчас на x86 эмулируются 64 битные типы.

УБ же, ну?, эх морковка ты морковка

Где? Обведи красным.

верней она скорее всего есть

Есть и продаётся.

Но при написании кода можно забыть о таком

Так и о проблемах с short можно было бы забыть, ведь и оставшиеся малопопулярные платформы могут стать little-endian.

преобразует операции над char в операции над минимальной единицей uint16_t.

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

Так и о проблемах с short можно было бы забыть, ведь и оставшиеся малопопулярные платформы могут стать little-endian.

На них хотя бы запускается UNIX. Осталась вроде только одна платформа с исключительными BE? Но нужно учесть что BE используют не только машины, но и протоколы и VM.

Так в этом-то и проблема.

В чем проблема, какая? Это забота авторов компилятора как они будут выкручиваться, что бы предоставить нормальные байты.

char net_char_array[100];
socket_read_to(net_char_array[); 
uint16_t val = ntohs(*(const uint16_t *)net_char_array);

…и схлопотать проблему с алиасингом, да ещё и выравнивание может по рукам дать.

Правильно будет или использовать type punning через union, или копировать данные в целевую переменную с помощью memcpy().

char совместим с другими типами, но вообще memcpy надо в реальном коде, да.

Байты в 16 бит - нормальные, это у других эти 8-битные слишком короткие.

char совместим с другими типами.

Это когда char алиасит другие типы, но не наоборот.

int i = 0;
char *pc = &i; // Норм

char c[sizeof(int)] = {0};
int *pi = c;   // UB

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

нужно будет реализовывать uint8_t

Не встречалась мне информация об обязательности этого типа.

Существует ли компилятор который действительно превратит это в проблему? Я ожидаю что это станет одобренным поведением, сразу после включения информации о том что char это 8 битный байт.

Если этого не будет, значит уж точно за пределы мигалок светодиодами такая машина никогда не выйдет.

А на них портативные диктофоны и плееры, сотовые телефоны работают.

Назови уже.

Я это и назвал мигалкой. Сейчас сумма этих вещей называется смартфоном, где стоит нормальный процессор.

The following types are required:

int8_t
int16_t
int32_t
uint8_t
uint16_t
uint32_t

Так это же требование для POSIX-совместимых систем. На них комфортнее.