Зависимости и совместимость вниз и вверх

нет совместимости вниз и вверх по версиям

Есть. В пределах последнего числа версии.

как на венде?

В смысле, таскать с собой варианты остальных чисел версий? Есть некоторые в рамках LSB, или с припиской compat в названии. Также какие-то из snap, flatpack, или как их там, таскают прямо с собой зависимости, или менеджер nix может в большей степени орудовать разными версиями. portage где-то посередине между nix и всякими apt, yum. Есть еще контейнеризация.

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

Как устроены в линуксе зависимости

Линукс это ядро, какие зависимости? Читай о deb, rpm.

и почему нет совместимости вниз и вверх по версиям как на венде?

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

нет совместимости вниз и вверх по версиям как на венде

А это не так просто устроить.

Ну, если только ядро рассматривать, то совместимость не бинарная и на уровне заголовочных исходных файлов. В разных сборках адреса функций не сойдутся, вроде. Для сохранения бинарной совместимости есть DKMS, и работает пока есть эти функции.

В userspace совместимость как-то сохраняется динамической линковкой или чем-то еще, не особо разбираюсь. Но в gentoo, например, не обязательно всегда пересобирать всё при обновлении компилятора, а только libtool.

А проще можно? Почему на старый дистр я не могу ставить новые проги и на новый дистр не могу ставить старые проги?

А это не так просто устроить.

Ну линукс же, же это «простота»? Почему же так неудобно сделанно?

Также какие-то из snap, flatpack, или как их там, таскают прямо с собой зависимости, или менеджер nix может в большей степени орудовать разными версиями. portage где-то посередине между nix и всякими apt, yum. Есть еще контейнеризация.

Или в венде совместимости вверх и вниз обеспечиваются контейнерам которые все зависомости таскают с собой?

Я про контейнеризацию≈изоляцию, что близко к виртуальным машинам.
Нет

Ну линукс же, же это «простота»?

Нет, это возможность. Просто, когда статически собрали.

просто≠удобно

Зависимости для слабаков, use Slackware, Luke

Не того троллируешь, сам виндузятник.

+1, там проблемы устранены можно сказать, есть базовая система - A, AP, итд. Пакеты легко адаптировать, что то заменить тоже.

Моя слака! я вон даже apt/dpkg прикручивал.

Или в венде совместимости вверх и вниз обеспечиваются контейнерам которые все зависомости таскают с собой?

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

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

Это классическая пакетная система линукса, типа deb или rpm.

Есть более современные подходы, такие как Snap (который в Ubuntu уже по умолчанию) и Flatpak, там с совместимостью все сильно лучше. То есть идет развитие в сторону большей простоты и удобства для пользователя.

почему нет совместимости вниз и вверх по версиям как на венде?

Потому что большинство авторов библиотек не хотят её делать и постоянно ломают совместимость. Например GTK. Stable API nonsense.

В смысле, таскать с собой варианты остальных чисел версий?

В Windows для системных библиотек нет over 9000 версий, вместо этого в существующую библиотеку добавляют новый функционал не ломая старого. в результате в Windows 95 и Windows 10 есть библиотека с одним и тем же именем user32.dll и во всех версиях есть CreateWindowExA. А в Линуксе бардак вроде libsomelib3.so.54.2.8-135, так что бинарную совместимость в принципе нельзя сделать, имя файла библиотеки другое и динамический загрузчик её не найдёт.

По разному. Да и что системные, те что в папке windows? У .NET четко видно разные версии в реестре и по папкам. Причем, ставится конкретная, а прошлые в комплекте:

In addition, .NET Framework 3.5 also installs .NET Framework 2.0 SP1 and 3.0 SP1

Но ветка 4 ставится отдельно.

Те же «Visual C++ Redistributable» ставятся по отдельности, с разными разрядностями, разными версиями, причём те, что притащили с собой приложения могут быть немного устаревшие, с меньшим последним числом, но установиться рядом. В списке установленных программ их легко может быть больше десятка.

~ $ winetricks dlls list |grep ^vcrun
vcrun2003                Visual C++ 2003 libraries (mfc71,msvcp71,msvcr71) (Microsoft, 2003) 
vcrun2005                Visual C++ 2005 libraries (mfc80,msvcp80,msvcr80) (Microsoft, 2011) 
vcrun2008                Visual C++ 2008 libraries (mfc90,msvcp90,msvcr90) (Microsoft, 2011) 
vcrun2010                Visual C++ 2010 libraries (mfc100,msvcp100,msvcr100) (Microsoft, 2010)
vcrun2012                Visual C++ 2012 libraries (atl110,mfc110,mfc110u,msvcp110,msvcr110,vcomp110) (Microsoft, 2012)
vcrun2013                Visual C++ 2013 libraries (mfc120,mfc120u,msvcp120,msvcr120,vcomp120) (Microsoft, 2013)
vcrun2015                Visual C++ 2015 libraries (concrt140.dll,mfc140.dll,mfc140u.dll,mfcm140.dll,mfcm140u.dll,msvcp140.dll,vcamp140.dll,vccorlib140.dll,vcomp140.dll,vcruntime140.dll) (Microsoft, 2015)
vcrun2017                Visual C++ 2017 libraries (concrt140.dll,mfc140.dll,mfc140u.dll,mfcm140.dll,mfcm140u.dll,msvcp140.dll,msvcp140_1.dll,msvcp140_2.dll,vcamp140.dll,vccorlib140.dll,vcomp140.dll,vcruntime140.dll) (Microsoft, 2017)
vcrun2019                Visual C++ 2015-2019 libraries (concrt140.dll,mfc140.dll,mfc140u.dll,mfcm140.dll,mfcm140u.dll,msvcp140.dll,msvcp140_1,msvcp140_2,vcamp140.dll,vccorlib140.dll,vcomp140.dll,vcruntime140.dll) (and vcruntime140_1.dll on win64) (Microsoft, 2019)
vcrun6sp6                Visual C++ 6 SP6 libraries (with fixes in ATL and MFC) (Microsoft, 2004)
vcrun6                   Visual C++ 6 SP4 libraries (mfc42, msvcp60, msvcirt) (Microsoft, 2000)```

А всякие lib* держат в своей папке. Они совсем не системные и обновляются только с программой.

У .NET четко видно разные версии в реестре и по папкам.

Это не базовый системный компонент, он работает поверх системных библиотек вроде kernel32.dll, user32.dll. Дистрибутив .NET устанавливается и работает на ReactOS.

Visual C++ Redistributable

Это тоже не системный компонент, а реализация поверх kernel32.dll.

А это?

APIs in Windows 8’s api-ms-win-core-file-l1-2-.dll got moved to api-ms-win-core-file-l1-2-1.dll in Windows 8.1.

Это всё обёртки над обычными kernel32.dll, user32.dll и т.д..

Export Directory  
Module Name: api-ms-win-core-file-l1-1-0.dll
Ord.	Name	Address
1	CompareFileTime	kernel32.CompareFileTime
2	CreateDirectoryA	kernel32.CreateDirectoryA
3	CreateDirectoryW	kernel32.CreateDirectoryW
4	CreateFileA	kernel32.CreateFileA
5	CreateFileW	kernel32.CreateFileW
6	DefineDosDeviceW	kernel32.DefineDosDeviceW
7	DeleteFileA	kernel32.DeleteFileA
8	DeleteFileW	kernel32.DeleteFileW
9	DeleteVolumeMountPointW	kernel32.DeleteVolumeMountPointW
10	FileTimeToLocalFileTime	kernel32.FileTimeToLocalFileTime
11	FindClose	kernel32.FindClose
12	FindCloseChangeNotification	kernel32.FindCloseChangeNotification
13	FindFirstChangeNotificationA	kernel32.FindFirstChangeNotificationA
14	FindFirstChangeNotificationW	kernel32.FindFirstChangeNotificationW
15	FindFirstFileA	kernel32.FindFirstFileA
16	FindFirstFileExA	kernel32.FindFirstFileExA
17	FindFirstFileExW	kernel32.FindFirstFileExW
18	FindFirstFileW	kernel32.FindFirstFileW
19	FindFirstVolumeW	kernel32.FindFirstVolumeW
20	FindNextChangeNotification	kernel32.FindNextChangeNotification
21	FindNextFileA	kernel32.FindNextFileA
22	FindNextFileW	kernel32.FindNextFileW
23	FindNextVolumeW	kernel32.FindNextVolumeW
24	FindVolumeClose	kernel32.FindVolumeClose
25	FlushFileBuffers	kernel32.FlushFileBuffers
26	GetDiskFreeSpaceA	kernel32.GetDiskFreeSpaceA
27	GetDiskFreeSpaceExA	kernel32.GetDiskFreeSpaceExA
28	GetDiskFreeSpaceExW	kernel32.GetDiskFreeSpaceExW
29	GetDiskFreeSpaceW	kernel32.GetDiskFreeSpaceW
30	GetDriveTypeA	kernel32.GetDriveTypeA
31	GetDriveTypeW	kernel32.GetDriveTypeW
32	GetFileAttributesA	kernel32.GetFileAttributesA
33	GetFileAttributesExA	kernel32.GetFileAttributesExA
34	GetFileAttributesExW	kernel32.GetFileAttributesExW
35	GetFileAttributesW	kernel32.GetFileAttributesW
36	GetFileInformationByHandle	kernel32.GetFileInformationByHandle
37	GetFileSize	kernel32.GetFileSize
38	GetFileSizeEx	kernel32.GetFileSizeEx
39	GetFileTime	kernel32.GetFileTime
40	GetFileType	kernel32.GetFileType
41	GetFinalPathNameByHandleA	kernel32.GetFinalPathNameByHandleA
42	GetFinalPathNameByHandleW	kernel32.GetFinalPathNameByHandleW
43	GetFullPathNameA	kernel32.GetFullPathNameA
44	GetFullPathNameW	kernel32.GetFullPathNameW
45	GetLogicalDriveStringsW	kernel32.GetLogicalDriveStringsW
46	GetLogicalDrives	kernel32.GetLogicalDrives
47	GetLongPathNameA	kernel32.GetLongPathNameA
48	GetLongPathNameW	kernel32.GetLongPathNameW
49	GetShortPathNameW	kernel32.GetShortPathNameW
50	GetTempFileNameW	kernel32.GetTempFileNameW
51	GetVolumeInformationByHandleW	kernel32.GetVolumeInformationByHandleW
52	GetVolumeInformationW	kernel32.GetVolumeInformationW
53	GetVolumePathNameW	kernel32.GetVolumePathNameW
54	LocalFileTimeToFileTime	kernel32.LocalFileTimeToFileTime
55	LockFile	kernel32.LockFile
56	LockFileEx	kernel32.LockFileEx
57	QueryDosDeviceW	kernel32.QueryDosDeviceW
58	ReadFile	kernel32.ReadFile
59	ReadFileEx	kernel32.ReadFileEx
60	ReadFileScatter	kernel32.ReadFileScatter
61	RemoveDirectoryA	kernel32.RemoveDirectoryA
62	RemoveDirectoryW	kernel32.RemoveDirectoryW
63	SetEndOfFile	kernel32.SetEndOfFile
64	SetFileAttributesA	kernel32.SetFileAttributesA
65	SetFileAttributesW	kernel32.SetFileAttributesW
66	SetFileInformationByHandle	kernel32.SetFileInformationByHandle
67	SetFilePointer	kernel32.SetFilePointer
68	SetFilePointerEx	kernel32.SetFilePointerEx
69	SetFileTime	kernel32.SetFileTime
70	SetFileValidData	kernel32.SetFileValidData
71	UnlockFile	kernel32.UnlockFile
72	UnlockFileEx	kernel32.UnlockFileEx
73	WriteFile	kernel32.WriteFile
74	WriteFileEx	kernel32.WriteFileEx
75	WriteFileGather	kernel32.WriteFileGather

1. Винда обеспечивает обратную совместимость, поэтому программы, работавшие на в2к работают на в10. Линуксовые дистрибутивы клали болт.

2. Windows SDK позволяет выбрать таргет. Можно собирать свежим SDK под старую Винду. Благодаря этому новые программы можно собрать так, чтобы они работали на старой Винде. Для линукса SDK нету. В составе каждого линукса идёт тулчейн и девел пакеты, позволяющие собирать только под эту версию только этого линукса. Lsb SDK заброшен.

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

Топикстартера не интересует стабильность юзерспейсного интерфейса ядра. Его интересует совместимость программ с юзерспейсом. Он же спросил

А проще можно? Почему на старый дистр я не могу ставить новые проги и на новый дистр не могу ставить старые проги?

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

Воот это уже ближе. А почему так? Почему не сделать как в венде, удобнее же?

Линуксовые дистрибутивы клали болт.

Почему? Если я хочу старую прогу на новом дистре - нельзя. Если я хочу новую прогу на старом дистре - нельзя.

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

Это меня интересует, почему так сделанно?

А в Линуксе бардак вроде libsomelib3.so.54.2.8-135, так что бинарную совместимость в принципе нельзя сделать, имя файла библиотеки другое и динамический загрузчик её не найдёт.

В этом смысле венда лучше? Почему в линуксе так неудобно в этом плане? Нет денег?

Потому что большинство авторов библиотек не хотят её делать и постоянно ломают совместимость

И в третий раз спрошу, почему так неудобно делают?

И чтом вместо зависимостей? Красноглазые рецепты? Что будет если допустим не будет сайта с рецептами?

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

То есть лучше не лезть в dephell? Проще комилить чем возиться с зависимостями?

Slackware и зависимости (комментарий)

То есть самому вручную разруливать зависимости проще?

Почему на старый дистр я не могу ставить новые проги

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

Оптимальная стратегия — по умолчанию пользуешься версиями из репозитория, если конкретная программа нужна свежая — берёшь AppImage. Всё просто.

А ещё (хитро улыбаясь) подскажи-ка: я могу сейчас легально купить у майкрософта MS Office (нормальный, не 365), если у меня хотя бы Windows 8.1 (про XP всякие даже не говорю)? Или с меня потребуют на десятку переходить?

И в третий раз спрошу, почему так неудобно делают?

Непрофессионализм. Библиотеки пишет кто попало в свободное от работы время и за качеством не следят. В Microsoft библиотеки пишут профессионалы сотрудники компании в рабочее время и за результатом работы следят.

Нет денег?

Примерно так.

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

Нет, в Windows системные библиотеки (ntdll.dll, kernel32.dll, user32.dll и т.д.) никто с собой не носит и они несовместимы между разными версиями Windows. В отличии от Линукса, в ядре Windows номера системных вызовов нестабильны и меняются в разных версиях. Совместимость обеспечивается только на уровне бинарных интерфейсов библиотек.

Воот это уже ближе. А почему так?

Ещё одна из причин в том, что в Линуксе хотят «свободы», то есть возможность установить что угодно в любой комбинации с разными параметрами сборки и т.д.. Для каждой функции есть множество независимых библиотек. Тулкиты: Motif, GTK 1, 2, 3+, Qt 3, 4+, WxWidgets, Tk и др. GUI серверы: X.Org, Mutter, KWin, wlroots-based. Звук: Phonon, GStreamer, OSS, ALSA, PulseAudio, PipeWire. Init: SysV init, Upstart, OpenRC, Systemd, и др.. Также в экосистеме Линукса многие библиотеки разрабатывают разные разработчики и нет силы, принуждающей их следовать единому стандарту. При таком подходе сложно обеспечивать обратную совместимость.

совместимости вниз и вверх по версиям как на венде

Это как когда в XP запускаешь свежий софт, а он просто не стартует, потому что ABI обновили? Или как когда в win7 запускаешь свежий софт, а в нём аппаратное ускорение не работает, потому что софт требует новые api?

потому что ABI обновили

ABI там с времён Windows 95 не обновляли. Новые программы не запускаются на Windows XP потому что используют новые API функции, которых нет в Windows XP. Если эти функции не использовать (в том числе и рантаймом C++), то всё будет работать.

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

Ну так есть glibc

А есть musl.

можно собирать программу под по возможности старым glibc.

Это требует очень сильного колдунства. Какого-нибудь SDK под это я не видел.

Зачем SDK. Даже если не ставить этот glibc специально, можно взять виртуалку с дистрибутивом постарше.

А musl для тех, кто точно знает, что он делает и кого уж точно не испугает сборка из исходников.

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

А если надо старая glibc и новые библиотеки и компилятор? Да и виртуальная машина — это лишние проблемы и тормоза. Хотя бы через chroot работало.

А musl для тех, кто точно знает, что он делает

Посмотрим… Местами он более прогрессивный чем glibc и у него более свободная лицензия. Дистрибутивы могут начать массово на него переходить.

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

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

И не надо сильно пугать ТСа.

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

Спасибо так понятнее! В чем конкретно проблема ситуации? В базарном(непрофессионализм, отсутствие единства) типе разработки? За что тогда любят и пользуют линукс? Только потому, что он бесплатный?

В базарном(непрофессионализм, отсутствие единства) типе разработки?

Да.

За что тогда любят и пользуют линукс?

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

Я вижу 2 основные проблемы, которые постоянно мешают лично мне:

1. Библиотеки постоянно ломают abi, не меняя sonumber, что не даёт установить несколько версий одной библиотеки рядом
2. Программы линкуются к приватным api библиотек (Привет, KDE!), для которых нельзя гарантировать неизменность abi, либо с библиотеками, которые вовсе не имеют стабильного api, и не предназначены для использования вне материнского проекта.

Если я хочу старую прогу на новом дистре - нельзя

Можно.

Если я хочу новую прогу на старом дистре - нельзя.

Ну, а это везде так. Для новых прог нужна новая ОС.

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

Спасибо, теперь понятнее.

И чтом вместо зависимостей?

Опциональные зависимости есть.

Что будет если допустим не будет сайта с рецептами?

./configure && make

В сотни раз проще.