On 2021/02/16 14:25, John Paul Adrian Glaubitz wrote: ---- I have MANY programs on my machine from Win XP days and probably a few from before and they still run. You are talking about programs that did their own thing w/the underlying HW -- many graphics programs didn't use the DirectX interfaces or opengl, but ones that did still run. Problems with old programs that were tied to hardware access are not a software-library-versioning problem, so please don't confuse the issue. ----- Win7 came with a WindowsXP mode for the few programs that wouldn't work on newer version -- mostly ones that did thing using the 16-bit API that WinXP supported from Win95/98 days. I did say 10-20 years ago, not 25 years ago -- but those were because of changing HW, not because new library versions were incompatible. --- Actually you are bullshitting us. There was no linux 30 years ago this month and V1.0 didn't come out until 1994. I'm pretty sure it wasn't binary compatible. Even when the linux kernel doesn't break user space code, glibc will refuse to run on older kernels. Old apps need to keep around the old libs. But then you are saying what I said in saying that users need to provide the libraries -- it's not handled by the OS and that makes running older programs unviable as package managers like rpm, remove older versions of libraries when you upgrade, making it very difficult to support older progs that worked w/older libs. That said -- most linux progs don't link to shareable object libraries even using the major number. Some do, but when did you see someone linking with glibc-1 vs. glibc-2. As for glibc compat, theoretically under semantic versioning, glibc 2.1 should be compat with glibc 2.33 -- so again, I ask: Why are all the apps in TW being rebuilt w/new glibc vs. being replaced as those apps are updated?

On Tue, Feb 16, L A Walsh wrote: Seems you mix up Tumbleweed as rolling release distribution with openSUSE Leap/SLE as stable distribution. In the first case, you have always the newest stuff, in the later case, you have stable interfaces, with the drawback, this is old code. Tumbleweed tries the best to provide all the new, shiny features in a stable way, Leap and SLE tries eveything to stay compatible without providing all the new features. You can do that still today. If a library does not use symbol versioning and changes incompatible without changing the soname, it's a bug. If you would understand a little bit about how starting ELF binaries works, it would be pretty clear that you can have only one ld.so, and thus only one version of glibc. Which itself is already incorrect, you can install multiple versions of glibc in parallel, but that's really not easy and you don't want that as normal user. And: everything compiled against glibc 2.x still works with glibc 2.33 today. The glibc developers are doing really a great job in keeping the ABI stable. There is absolute no need to keep older glibc versions in parallel. Maybe Leap would be the right distro for you? ??? Where did Linux stopped using the correct version to link with? All libraries with a public interface have a soname and many of them even symbol versioning. Else see above. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Felix Imendoerffer (HRB 36809, AG Nürnberg)

On 2021/02/16 23:30, Thorsten Kukuk wrote: Windows gets around it by having multiple so's -- installing the 'so' that each program compiled with. --- That answers my question about how many corporations are using TW. Though to be honest, I want to update my linux system about as often as I change Win OS's. Win 7 was out for about 12 years w/support. I was an early adopter and am still using it. But never was Win7 keeping me from using new programs (well until recently). How many progs from an opensuse release from 2008 would work on a system from today? ---- ld.so is supposed to be a loader. It works with other libraries just fine. It has intimate knowledge about glibc, but it doesn't need it from other libc (musl?) implementations. ---- The user doesn't keep the multiple lib versions in Windows -- the OS does. It's not a matter of "can't" its a matter of the linux world being about 15 years behind in supporting new progs and old on the same OS. MS used to have 'dll/so' "hell", because they used to only be able to have 1 copy of a lib loaded in shared mem by the OS, but they fixed it so different progs can have different versioned libs -- why hasn't linux gone that route?

On 2021/02/17 09:34, Jan Engelhardt wrote: --- Back when disks were sized in MB, I was more concerned about that. However it doesn't seem to be an issue on today's disks. --- Why would 1 program load two or more versions? It only binds with 1. --- The program binds with the lib it was built against in a similar way as binding with a static lib, but if that library is already installed, on a given machine, it can be shared with other programs that use the same version. Ultimately MS uses GUID's for describing uniq libraries. I've never heard of a program binding to 2 different libraries, but that seems like some sort of quantum binding where something can be 2 things at once. But once the program binds, it decays into 1 fixed state, no? ---- Satisfying dependencies within 1 daily TW release is 1 thing, but I'm talking about satisfying dependencies for all programs the user has built or installed during the life of the OS's installation on the machine. I shouldn't have to wipe my machine's OS during it's lifetime unless there is a problem, but given that I build my own packages and rebuild my own versions of some from included sources, that means there are dependencies on my machine for some library versions that wouldn't be listed in a repository's manifest. I would expect that the libraries I build with aren't going to suddenly become unavailable for programs I've built myself. Not being able to build and install your own SW makes a personal computer a bit less useful, especially where open source is involved.

четвер, 18 лютого 2021 р. 00:40:06 EET L A Walsh написано: You should understand, that different files on disk also mean different code segments in memory. While code of one .so in different processes uses same segment shared between all processes. It's not just disk, but RAM overhead too. -- Kind regards, Mykola Krachkovsky -- Найкращі побажання, Микола Крачковський

Please, we should never use this argument. To say "openSUSE is free, so don't expect the quality of payed system" destroys all the hard work invested in it. With these attitude we can simply put on https://get.opensuse.org/ some big red warning "Don't use it, it is free and therefore it is bad". And I think, we don't want that.

On 2/17/21 8:30 PM, Axel Braun wrote: If that was true, we wouldn't have a business model. No, even Linux doesn't just run. Adrian

On 17/02/2021 20.56, Jan Engelhardt wrote: That's a good point. -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)

On Wednesday 2021-02-17 21:38, John Paul Adrian Glaubitz wrote: well, then ... of a CERTAIN paid system, usually the one that was mentioned in the discussion. Quality: Only available for one or two architectures. Does not even come with the basics like an office writer or spreadsheet. Value: It also isn't libre, which is hard to put a concrete value on, but it's valuable nevertheless. So Windows falls short both in quality and value-per-euro.

On 2/18/21 6:49 AM, Thorsten Kukuk wrote: Actually, you do as large amounts of open source code is developed by paid developers, for example for the Linux kernel [1]. The basement dwelling Unix neckbeard that is primarily driving the open development at no charge has been a myth for a very long time already. Most development in products like Firefox, the kernel, GCC, binutils, Go etc is done by paid developers. There is no free lunch. Adrian > [1] https://www.linuxfoundation.org/blog/the-top-10-developers-and-companies-co…

Am 18.02.21 um 07:42 schrieb John Paul Adrian Glaubitz: That's where most of the money ends up, but Thorsten is probably right that most SUSE customers have more the support and maintenance in mind when they pay you. Let's be fair, it's a bit of both (if we include volunteer contributors at other building levels and without facial hair). Of course some projects have mostly corporate contributions, but there are also many (often smaller) projects that have mostly volunteer contributors. Technically the lunch is free: all of these programs are available free of charge, there are no hidden costs and there is no other way you end up paying for it. It's not even like social media where you pay with your data. Software and other kinds of "IP" have near zero marginal cost. So somebody has to pay for it, but once its paid for, everybody can get it for free if the license allows it. There is virtually no cost to providing the software to more people, so the "no free lunch" theorem doesn't apply in my view. Which is not a bad thing: people in third world countries can also download and install openSUSE for free and none of us need to bothered by it (ignoring the support cost and just considering the software). Best regards, Aaron

On 2/19/21 8:19 AM, Johannes Meixner wrote: I'm pretty sure that paid SUSE developers work on support for new hardware and not just on the stuff that we are selling to enterprise customers. Takashi, for example, is the primary maintainer of the Linux sound stack and he is being paid for that work. In Debian, both the toolchain and the kernel maintainers are paid professionals. Many Debian developers work for companies like Canonical, Credativ or Collabora. But I wasn't so much focusing on SUSE or other distribution vendors only. A Linux distribution is the result of the work of thousands of developers with most of the work share being done by upstream projects and very often by developers. So why you don't have to pay for openSUSE itself, it's still very much the result of paid work which was cross-subsidized by customers buying hardware or support contracts. Try projects like OpenBSD as a counter-example which don't have large corporate backings and as a result, OpenBSD's hardware support is very limited as compared to Linux - something which you can't blame them for given the lack of corporate funding and manpower. Adrian

Hello, On 2021-02-19 09:13, John Paul Adrian Glaubitz wrote: paid coffee of course - paid by our customers - shudder - crazy world ;-) Kind Regards Johannes Meixner -- SUSE Software Solutions Germany GmbH Maxfeldstr. 5 - 90409 Nuernberg - Germany (HRB 36809, AG Nuernberg) GF: Felix Imendoerffer

On Fri, Feb 19, 2021 at 08:56:23AM +0100, John Paul Adrian Glaubitz wrote: Worth remembering that many volunteers' interest was sparked by their rights to accessible code and having their own itch to scratch, which has led many into aligned full time jobs. The first two-line commit might have taken moments to type, but was perhaps the outcome of weeks going down the rabbit-hole, trying to isolate an issue and fathom out how the blocks/sub-systems/projects interacted. Harnessing and directing some of that enthusiasm is perhaps the art of a successful distro or opensource project. Daniel

Am 19.02.21 um 08:56 schrieb John Paul Adrian Glaubitz: Perhaps we're just talking about different things here. I'm well aware where most of the code in the kernel, GCC and LLVM comes from. But Tumbleweed has ~15,000 packages, and the overall ecosystem does have a lot of volunteer contributions. As important as the kernel, compiler and browser are, a Linux distribution is much more than that. Best regards, Aaron

On 2021/02/17 09:53, John Paul Adrian Glaubitz wrote: --- But you might want the new version of the latest CMS to go with your website. If you wait for 2-3 years till it comes out in leap, you've missed most of your window. Similarly with any product, one might need a new feature from a newer product and might even be able to _test_ the product to see if it meets one's needs. That does not mean one wants an unstable system by replacing all packages every day as could be the case w/TW. --- 0 and 0. Is there a point? You might claim I paid some fee for Win, but that's a tax on the HW platform I don't have much choice about. Given that its the same cost for openSUSE as Windows. If oSS published a broken, gimped or "nerf"ed package, it _should_ be possible to build it myself and I could, (and _have_) sent back the fixes. With Windows I wouldn't be able to do that, though also, w/Windows, I'd be less likely to know the state of the package. So what's your point? --- Good thing the MS platform never has security problems. Oh wait -- they do, but don't seem to have the same security problem(s) Linux has. Are you implying Linux can't handle security problems as easily as MS can? Perhaps Linux should copy MS's methodology for that -- i.e. providing multiple versions. --- That would be an onerous burden if it was what anyone did. Fortunately that's not what MS or developers on that platform do. Presenting a straw-man problem as the counterpoint to the broken linux way, is pointless. --- So in addition to not knowing how MS solves this issue you also say it can't be solved and 'punt' with a poorly integrated solution that dwarfs the disk cost of shipping an update.exe along with the app-install.exe that only loads the minimal set of libs needed and that are not already on the users machine. --- "a sandbox environment in which users can run application software in isolation from the rest of the system" - wikipedia -- isolated from the rest of the OS doesn't mean "integrated" nor dedupped. Flatpak's store shared resources in a "com.company.App/i386/version" os-tree. So for TW, that'd be a different lib for each day TW is released. i.e. zero deduplication. So far, I'm not seeing solutions that allow me to rebuild suse apps from source rpm's.

On Fri, Feb 19, 2021 at 06:08:37PM -0800, L A Walsh wrote: That multiplies the work for them, and at some point they decide to stop supporting soe of the old libraries and they stay forever broken yet your abandonware software will keep using it forever. Yes, MS developers don't their code is part of the platform and they do maintain the parts of the platform that are still under supporte. But application developers do. That's actually what MS suggests them to do. Well, they don't solve it. They update the MS platform and punt updating any other libraries to the software vendors. So when there is a bug in a popular library every vendor that uses it must release update of ther software with the bundled library. If the software in question is some abandonware that is no longer developed or some freeware side project that gets little attention you are out of luck. It will stay broken for a long tie or even forever. You don't use flatpak to install TW. You use flatpak to install applications that are not available on a stable distribution (in the version you want). Of course, doing that has some disadvantages. At the very least flatpak aims to do some deduplication of installed libraries as opposed to full vendoring other distribution-neutral packaging does. Best regards Michal

On 2/18/21 1:49 AM, L A Walsh wrote: Well the tarball for setserial hasn't changed in atleast 14 years, according to the changelog it hasn't changed version since 2000, the only changes in the last 10 years were disabling init scripts and moving stuff into /usr so atleast some :-) -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B

On 19/02/2021 15.00, Dominique Leuenberger / DimStar wrote: L A has a complicated problem you may not have been following. I don't remember all of it. A TW machine had some hardware problem and could not be updated for some months. The compression format of rpms changed meanwhile. The rpm code in the machine can not cope with the new format and the machine can not be updated. L A has been trying to build rpm program or libraries that can be installed on that system and tha can cope with that new format, but failed. There is a bugzilla about it. Part of the problem is people telling to use OBS and L A refusing for privacy or enterprise reasons, and rebuilding the rpm from published rpm source code seems to be impossible, unless done at the OBS, which is external to L A. I may of course have gaps in my understanding :-) -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)

On 19/02/2021 23.14, Axel Braun wrote: Arguably much more complex that rpmbuild command :-? -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)

On 20/02/2021 10.55, Simon Lees wrote: Certainly. OBS is easier on the maintainer, no doubt. After a learning curve. But not for someone doing spot builds, for whatever reasons - say, machines isolated from internet for privacy or security. It is just an opinion, a layman opinion perhaps, but I think the source rpms should be enough to re-build any package, they should work. Otherwise, I have my doubts we are "providing the source code" as per the free code licenses. -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)

Am Samstag, 20. Februar 2021, 00:23:57 CET schrieb Jan Engelhardt: Sure. But if you want just the result to be private it works fine. So once you have all dependencies you can use -o to build. SOMEHOW one has to determine all dependencies, independent what if rpmbuild or osc build is used, and needs to get this on the disk. @Carlos - I havent used rpmbuild since I use osc. Cheers Axel

On 20/02/2021 10.24, Axel Braun wrote: And I have never used osc because it is way to difficult to learn. Yes, I tried. -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)

Am Sonntag, 21. Februar 2021, 21:43:20 CET schrieb L A Walsh: As OBS sets up a clean build environment you can compile against targets that do not match your setup I feel here's the gap: Depending on how 'individual' your system is your rpm installs on your machine, but on no other. Having a clean and reproduceable build environment is a *big* advantage in OBS.... Cheers Axel

On 2/22/21 1:47 PM, L.A. Walsh wrote: This is simply not true otherwise tumbleweed users wouldn't have been able to upgrade similarly Leap users wouldn't be able to migrate to tumbleweed (which they can) as Leap still has 4.14 which first came around early 2018. Unfortunately if you don't have rpm 4.14 or later on your machine its no longer in a state we support and you really only have two options, 1. use the upgrade function on the installation media, 2. The following repo [1] contains multiple rpm packages, the highest version one will be capable of installing rpm 4.14.1 from Leap 15.0 [2] otherwise upgrades wouldn't have been possible. From there you can update to the latest rpm provided in Leap 15.2 and then onto rpm 4.16.0 which is now the version in tumbleweed. From there you can reupdate everything or rebuild rpm from source or whatever you would like. If you are unwilling to try those things there isn't really anything we can do to further help you with your issues. 1. http://ftp5.gwdg.de/pub/opensuse/discontinued/update/leap/42.3/oss/x86_64/ 2. http://download.opensuse.org/distribution/leap/15.0/repo/oss/x86_64/rpm-4.1… -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B

---- How does this not seem like doublespeak, or speaking with a forked tongue? If someone doesn't already have their "upgrade ticket" in place, they can't get one. Instead, they should use os-reinstall media to reinstall all packages? I.e. upgrading to 4.14 and then 4.15 isn't supported. So how is that not the same as "not being able to upgrade to suse's current packages"? As I said before, if you are going to have an upgrade path that breaks if you don't upgrade within a specific window, then I would point out that the upgrade path is broken. My machine was offline from for ~4 months of last year. Before that time I could download packages and none of them required 4.15 to upgrade. After --- I tried one Dominique used. It was going to replace about 240 packages, remove about 40 others and add 10-15. One of those was glibc, which would leave any un-upgraded package, _stranded_, by default. Now she announces another rev of glibc, "requiring", probably another 200+ packages. Others here have claimed that a newer version of glibc should support older SW as well: On 2021/02/16 23:30, Thorsten Kukuk wrote: ---- However, Dominique says the large number of packages in Feb-12's release are because of all the packages linked with glibc and it being upgraded: On 2021/02/16 00:58, Dominique Leuenberger / DimStar wrote: --- So, which is it? If glibc is binary compatible, then why do so many packages need immediate upgrade when glibc is upgraded? Simon Lees wrote: --- Perhaps it's like the latest update -- all packages w/a glibc dep, are getting replaced -- do they need to be replaced or is this just chasing the latest update? But the reason the updates were possible is that for some window, there were rpm versions that could handle old and new. That window has passed. But that's the problem -- the rpm-binary that could speak both formats should have been statically linked so it could run on both. and would be runnable in the future. Even building an rpm on the Musl libc variant would work. FWIW, a static binarywith musl (if I don't have the name wrong), isn't hard to setup and takes about 1/6th the space. I have 4.11.3 on my system and have tried installing 4.14.1 and then tried building it -- same for 4.15.1 -- though it's in the new binary encoding, and won't be loaded by rpm's under 4.15 and 4.15 Simon Lees wrote: --- This matter is complicated by RH and Suse having some binaries in different locations, as well as moving the rpm-DB and changing to a new DB format. Simon Lees wrote: http://download.opensuse.org/distribution/leap/15.0/repo/oss/x86_64/rpm-4.1… --- Another FWIW, I working on my download script being workable with leap-15.0 (who knows, maybe I'll throw in leap-42.3 if I get the former working cleanly. I had to cook my own script for TW due to it changing package versions daily. with leap and predecessors, I could d/l binaries from the whole leap-42.3 window and easily integrate them, but w/TW, being released daily, I need to pull down the the file+ver list of the day and verify I get all the src+oss+non-oss associated with a 1day window and ensure I have the exact rel #'s from that 1 day window to ensure it all works together. That script I got working in the past few weeks. Just started on upgrading it for leap last week, that may take a while again, as I do get distracted and have other projects/work I need to do at the same time, and my clones' organic brains are still slow to update. As soon as they/I get the nextgen brains in w/fiber interfaces, that work should go much faster.. ;^/. Sigh... Meanwhile, for key pieces of SW like a dual-protocol rpm, they really should be statically built-to-last.

On 2/23/21 5:31 PM, L A Walsh wrote: In that case something unusual was going on with your machine, generally our supported upgrade is two generations of SUSE products, we are still testing upgrades from 42.X and 15.0 which puts the supported upgrade path in the category of years rather then weeks or months, you mentioned in another thread you ended up with an old version of RPM, I was just trying to help you get a working version back. In Tumbleweed we take a pessimistic view of the world and rebuild and publish a new version of any package if one of its dependencies change regardless of if it does or doesn't break binary compatibility. The release managers like to rebuild the whole distro a couple of times a year to be safe, glibc provides a good time to do this as we would have been rebuilding most packages anyway. We don't do this for updates in released products such as SLE and Leap however, there we have very strict policies on updates being binary compatible. In short they don't need to update but its a design decision that they do, it saves effort in the case that a non binary compatibility breaks in a way that would affect things (again we don't allow this in Leap / SLE updates). This has been discussed in the past, from an openSUSE perspective we would be far more interested in a statically linked zypper which has fun issues and isn't really needed in the end because we provide working upgrade paths for people on standard systems. but have you tried using the 4.14.1 to install the 4.15 and then the 4.15 to install the now current 4.16. Then you can use 4.16 to build and install whatever you'd like. Shouldn't be, the openSUSE packages should provide all the migration needed for this if you install them in the right order. Well the supported way to update a system is `zypper dup` we will make sure that works there should rarely be a need for an openSUSE user to call rpm directly, especially when installing / removing / upgrading packages. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B

On Mon, Feb 22, 2021 at 10:20:09AM +1030, Simon Lees wrote: There is no such project. The packages are some obsolete TW snapshot. And building on Leap may or may not work - I think the new rpm spec file uses features of the new rpm so it is not buildable with old rpm. I suppose that at some point in the history of the rpm package it contained the new sources and was buildable with old rpm but you need to find that, rebuild with old rpm, and then you can install the current one. Not exactly nice experience. And it's quite possible that such sources were only present in some bootstrap project and locating them in OBS is pretty much impossible. Thanks Michal

On Tue, Feb 23, 2021 at 08:44:34PM +1030, Simon Lees wrote: Also from your analysis in your other mail it is clear that the rpm package is not months old but much older. According to the report the user did not upgrade for a few months but ended up with rpm 4.11 which is very old - 4.12 was introduced in 2014. So this is clearly some problem with the system - using package lock, having old software installed that prevents the rpm upgrade, or whatever. If you break it you get to keep the pieces. Can't do much about that. Thanks Michal

On Tue, 2021-02-23 at 10:50 +0100, Michal Suchánek wrote: There is so much speculation, it hurts. The only thing that really chaged was the payload compression format used in Tumblewed - we switched to zstd in Tumbleweed somewhen in 2020 (Snapshot 20200825) See also http://dominique.leuenberger.net/blog/2020/08/opensuse-tumbleweed-review-of… We had supported decompressing zstd payload for roughly a year beforehand. Leap 15.2's rpm version supports decompressing the zstd payload (and Leap's RPM package is not zstd compressed) In case you need/want to dup from something older, use the DVD/NET iso and do an offline upgrade (i.e. not on the running system). Cheers, Dominique

On Saturday, 20 February 2021 8:13:22 ACDT Carlos E.R. wrote: So nobody suggested downloading or creating a current Live DVD, booting from that (to ensure that the rpm version and libraries are current), then chrooting the problem system and updating that way (at lease for rpm and it dependencies)? Or is that too dangerous to try? -- ============================================================== Rodney Baker VK5ZTV rodney.baker(a)iinet.net.au CCNA #CSCO12880208 ==============================================================

On 2021/02/19 06:00, Dominique Leuenberger / DimStar wrote: ---- No -- we are talking about rpm. So install rpm from 10.2 and use it to install + upgrade from the current rpm-sources using the rpmbuild in 10.2. Might help if you use the same product. The rpm I have doesn't read the rpm's in the new compressed encoding. Would it have been that painful to have rpm that you ship today be installable on any tumbleweed system by statically linking it? Then someone can upgrade to some distro-specific-recoded rpm after that. Just having a cutoff at >=4.15 = only rpm that will read new rpm-formats, while <4.15 can't install 4.15 sorta sucks. People think shared libs are the answer because of security fixes, but not every program links with every lib. Furthermore, there are programs that are alot more useful to have "working" than worry about patching for a security fix that might happen once in a blue moon. If rpm needs a security fix, create 1 new static rpm that works everywhere. This is a problem -- creating static programs for things being able to open your rpm's old+new, is 1 program. Same might be true for a boot shell and 'mount'. Somethings are more important than being fragile and subject to not running on a system w/different libs or a different installation encoding.