[Discussion] A world in which Debian uses RPM

[canci]

I've meandered in my musings because I thought, if brainchild already presents us with a very wordy and vague description of their idea, then there aren't strict guidelines as to what to discuss. I thought anything was fair game.

And I'd concur with some of the posters here that I'm not convinced of the fact that this whole ostree/rpm paradigm is something super inevitable that one has to implement or die trying, but that there are other options. I mean, Devuan and Gentoo exist within the Linux ecosystem and the BSDs also don't just swallow everything shiny and new.
Are they missing out on a few shiny things like working Bluetooth devices and proprietary app du jour not working? Sure.

[brainchild]

And I'd concur with some of the posters here that I'm not convinced of the fact that this whole ostree/rpm paradigm is something super inevitable that one has to implement or die trying,

Have I made any suggestion remotely similar to one of OSTree being inevitable? Am I misunderstanding your remarks?

I believe I have made it plain that OSTree integration is one example of a path along which package systems have been evolving in some contexts. Other examples are available, and more will become available.

Actually, I have been most disappointed in some responses, not due to the resistance to or misunderstanding of the spirit of my remarks, but due to the lack of imagination, the tendency to assume that the status quo surely would remain indefinitely, simply because some are not immediately perceiving some desirable course of change.

All I consider inevitable is continuing evolution. The only opinion I firmly consider outrageous is that package management in Debian will remain indefinitely as it is at the current moment.

[anticapitalista]

To original question - no I can't.

[el_koraco]

All I consider inevitable is continuing evolution. The only opinion I firmly consider outrageous is that package management in Debian will remain indefinitely as it is at the current moment.

Package management in Debian will certainly undergo some changes. The thing which makes Debian what it is is not so much the package management system, but the packaging policy. The project is committed to a release cycle which ensures that no package lands in Stable which will do anything other than install and continue to work. OSTree is a solution to a problem that Debian simply does not have - instability in the main offering. It is thus conceivable that Debian adopts the rpm packaging format, but not very conceivable that it adopts a different kind of policy as anything other than a speculative sideshow, kind of like some people have been tinkering with Hurd or the FreeBSD kernel.

[LE_746F6D617A7A69]

Discussions do not require POCs.

AFAIN POC applies not only to a situation where someone wants to prove that something works - it's also used to prove that one solution is better than the other - f.e. by comparing various use cases/scenarios.

Now You're saying that POC is not needed - OK, so what (in Your opinion) should be discussed here?

The OP arguments are:
1. RPM+OStree is better than APT -> no technical proofs.
2. Most distros are using RPM -> no proof (any numbers?), and even if it's true, this is not a technical argument.
3. (threat) In some undefined future Debian will become the only distro using APT -> so what? Is there any problem with APT? Non-technical argument.

This is not a discussion - a single person came here ranting about how fantastic the RPM is, trying to convince everyone that there's no other way for Debian except switching to RPM.

It's at best hilarious.
.

[CwF]

It's at best hilarious.

,...here, hold my tea

lack of imagination, the tendency to assume that the status quo surely would remain indefinitely

Like there's a Great White swimming around somewhere wondering when he's going to develop Molars so he can enjoy the health benefits of seaweed. This presentation a flowery non-specific justification for perpetual shiny new syndrome.
Evolution occurs due to environmental pressures to do so, not boredom, or for the sake of making the next generation feel worthy,

Actually I'm disappointed it's being considered legit to discuss change for the sake of change so there is something to attach a new name to, while pinpoint criticism is dissuaded as unproductive. I didn't miss a thing and was ahead in anticipating not the argument, but the tactic. So I used the word arbitrary to describe the arena of the pointless point and flat out called the forthcoming 'unification' desire as invalid, and later gave reason.

How is there the need to point out ad hominem to LE? AYFK! The progression here is literally the construction of a straw man, with the clarifying link for my understanding, ayfk. Tactic, not reason.

The cynical view would be you've intentional thrown a wrench into the machinery here to disrupt with no intention to persuade. Discussions and Arguments are not at all separable concepts of 'style'. A discussion without any argument is a presentation.

OSTree is a solution to a problem that Debian simply does not have

Bingo.

I mention an Onion instead of a tree. It was passed up since there is no ongoing 'discussion' here but rather an ego's hammering. Reading some of the forums here I've hinted many times at my preferred method to address change with virtualization. The 'argument I've been making since the late 90's. We are decades now into actual hardware enablement of such methodology. Too much to lay out here, but simply the idea of segmentation and compartmentalization of 'everything' in a way very similar to the ancient concept of terminal/server with a new portability of each 'layer' and very much the way in which the greater cloud of today is actually operating.

Snaps, flatpacks and OSTree are totally out of place in this model and are the results of 'monetization' pressures and not the functional necessities of evolution. The superior Debian way is foundational in its ability to build any of the segments in this organically grown onion, and not itself be simply an ingredient. The majors M$, apple, and such are restaurants. Other foundationals like LFS, Gentoo, etc are food trucks. Vanity distros are cupcakes. Debian is simply a kitchen, a fully equipped kitchen.

Now I know I didn't really explain this mystic onion...It's in operation now and needs to evolve many new abilities. For instance, cow block device mobility along with the continuing blur between containers and full vm's as synonymous with local or remote distinctions. I'm all about eliminating friction to progress, but this thread is a 'transitional dummy package' and 'safe to remove'.

[donald]

Now You're saying that POC is not needed - OK, so what (in Your opinion) should be discussed here?

Anything specific to Debian, Technology, or F/OSS related.

[el_koraco]

cow block device mobility

Theoretically prudent, functionally useless, provided you are running the right distro. I have had four or five long running Arch installs in the past decade. Every time I would install with btrfs subvolumes and an idea of snapshoting before an upgrade. I would simply forget to snapshot, because a typical Arch install, provided you are using the repositories alone, has a tiny bit of breakage once a year. I am back to ext4 on Debian now, a single partition, simply because I do no ever expect to have to reinstall anything.

[brainchild]

Package management in Debian will certainly undergo some changes. The thing which makes Debian what it is is not so much the package management system, but the packaging policy. The project is committed to a release cycle which ensures that no package lands in Stable which will do anything other than install and continue to work. OSTree is a solution to a problem that Debian simply does not have - instability in the main offering.

No one thing makes Debian what it is, other than the incremental continuity of its community, just as no one thing makes China what it is, or Walmart, or the Greek language.

However, your premise, concerning the problems solved by OSTree, or not, is rather narrow, and not particularly accurate. Anyone wishing to consider the space critically certainly should learn about transactional updates in general, at least as a starting point, if not already familiar. Another point of interest might be the various Debian descendants currently using OSTree.

Meanwhile, all I can do is repeat, that the subject of the discussion is not OSTree.

[LE_746F6D617A7A69]

Now You're saying that POC is not needed - OK, so what (in Your opinion) should be discussed here?

Anything specific to Debian, Technology, or F/OSS related.

Is this a joke? - at least it looks like joke for me ...

But seriously: do You (I mean Debian project) need help in maintaining/development of APT? If so, then please speak openly.

Personally, I think that APT could be seriously speed-up by moving it to multi-threaded world - yes I think it's possible, by ensuring proper implementation of barriers/locking -> that will result in nearly linear scalability of performance.

Regards.

[CwF]

Theoretically prudent, functionally useless,..snip...I am back to ext4 on Debian now, a single partition, simply because I do no ever expect to have to reinstall anything.

Exactly right. You point out the difference between an integral solution within the particular OS and similar function provided from outside the OS.

So a single partition ext4 is the simplest "unit" which can adapt to runtime environment with minimal effort. Variable enumeration and init of the OS is not a significant extra effort, just some minor configuration additions. Simple single part ext4 is what I use. These 'images' can be used as a 'unit' or layered upon to provide a specific function so the unit is a base and its layer. The concepts of immutable base, snapshots and backups, and portability all externally provided function and included. In this way the particular OS and/or program mix can be anything and ignorant of these additional features. I use the same for windows OS's. I haven't needed to 'install' in that last 7 years and simply recycle, modify, and upgrade the past.

Continual upgrade through the generations is one of well known talents of the Debian way.

None of this requires any particular package manager to accomplish.

If you want to run the KISS empowered unit on bare metal, it's easy to do and you don't lose any of these advanced features it doesn't know about. The technologies that need focus are the many already in place and evolving, some not yet FOSS.

[brainchild]

Like there's a Great White swimming around somewhere wondering when he's going to develop Molars so he can enjoy the health benefits of seaweed. This presentation a flowery non-specific justification for perpetual shiny new syndrome.

No, you have flat out conflated two issues. The purpose of my comment, the one that prompted yours, above, was to give a prediction that evolution will occur along some path, not about which path, and my remark on the broader matter was in turn a response to the suggestion, repeated throughout by various other comments, that Debian has in some sense reached the terminus of its evolution, beyond which any further change would necessarily represent a degradation.

Thus, the more fitting analogy would be of a paleontological fish dismissing a peer who muses at the possibility of having a descendant that would not be bound to water.

Of course, I'm not suggesting that any animal descended from fish would ever fly, or even climb trees. Ultimately, a fish is distinguished from other animals by traveling and surviving underwater, and it does so remarkably well. It is pointless to consider why primates should climb, or birds should fly, as long as fish are happy swimming.

The cynical view would be you've intentional thrown a wrench into the machinery here to disrupt with no intention to persuade.

Yes, it would be cynical, and which then would be the one who is cynical, the one receiving the characterization, or making it?

Discussions and Arguments are not at all separable concepts of 'style'. A discussion without any argument is a presentation.

Yes, in a sense, you're right, because any discussion degrades into an argument the moment some hothead enters determined to manufacture one out of thin air, simply for the sake of participating in one. Honestly, I suggest you find a thread labeled "Argument for the sake of arguing" (if there are any, though I admit I haven't checked whether the forum administrators have provided the label as among the prescribed choices). Alternatively, you might visit a local bar, and swing a punch at some stranger seated peacefully. It always makes for an interesting evening. After letting out some steam, you might feel inclined to reread the thread so far, with the benefit of broader clarity.

The current post will be the last I will make in the thread for responding to comments that appear to me simply as instigation of argument for its own sake, rather than making productive contributions to the discourse. Otherwise, I'm afraid, the thread will degrade even further into one of everyone striving to repeat the same tired objections simply to have the last word.

[brainchild]

But seriously: do You (I mean Debian project) need help in maintaining/development of APT? If so, then please speak openly.

I think the suggestion was that any discussion is fair if it may in principle inform a future direction of the project, regardless of whether or not any particular individual prefers some particular direction. I take the comment at face value. I have not read any suggestion that maintenance of Apt is strained.

[CwF]

Personally, I think that APT could be seriously speed-up by moving it to multi-threaded world - yes I think it's possible

I thought it was in a limited way? It is beneficial for tracing for it to be sequential, and it does complexities through iteration, that's why I think Aptitude is faster for complex upgrades when done in a tty with so many of typical desktop and services not running.

[brainchild]

Personally, I think that APT could be seriously speed-up by moving it to multi-threaded world - yes I think it's possible

I thought it was in a limited way? It is beneficial for tracing for it to be sequential, and it does complexities through iteration, that's why I think Aptitude is faster for complex upgrades when done in a tty with so many of typical desktop and services not running.

I think the downloading and unpacking phases may be made parallel in principle, but application of the upgrades to the system would remain sequential. Only one worker may be allocated for the purpose of modifying the system, otherwise race conditions would emerge. Such changes would require some redesign and rewriting, especially with respect to separating unpacking from installation, currently handled by a single invocation of the base utility.

[brainchild]

If you want to run the KISS empowered unit on bare metal, it's easy to do and you don't lose any of these advanced features it doesn't know about. The technologies that need focus are the many already in place and evolving, some not yet FOSS.

Arch Linux is KISS. Slackware is KISS. Tarballs are KISS. Tape drives are KISS. Assembly is KISS. Single-core, 16-bit processors are KISS (what ever happened to 8-bit microcontrollers anyway?). MS-DOS is KISS (only the early versions, of course, before support was added for hard drives).

I'm sorry, was this the Debian forum?

[sunrat]

My girlfriend is KISS. Well, if I had one she would be...

I'm sorry, was this the Debian forum?

This is the Offtopic section.

[brainchild]

I'm sorry, was this the Debian forum?

This is the Offtopic section.

Crafty, and definitely not below the belt.

[donald]

But seriously: do You (I mean Debian project) need help in maintaining/development of APT? If so, then please speak openly.

I think the suggestion was that any discussion is fair if it may in principle inform a future direction of the project, regardless of whether or not any particular individual prefers some particular direction.

Pretty much but it does not always have to be Debian specific all of the time, nor does a topic have to set a flag on a hill for future Debian development, for example we could talk about processor development for architectures and so on and it would be fine.

I think most topics that foster some idea sharing and discussion are more than appropriate and welcome here. It is weird reading users saying that things and things cannot be discussed here at the same time as one of the administrators saying such topics are more than welcome and encouraged.

Anyhow regards of everything else I've learned a lot in this thread about different package management systems, I got a little smarter.

[brainchild]

It is weird reading users saying that things and things cannot be discussed here at the same time as one of the administrators saying such topics are more than welcome and encouraged.

Yes, I understand. I think some find irksome not being able to resolve a correct answer, more so than the subject matter not being narrowly targeted. At least, it would explain why so much frustration was noisily vented over my not giving any premise (e.g. any "argument") that might be negated. In fact, the frustration ran so steep that easily-refuted premises simply were attributed to me inaccurately, along with, of course, the actual refutations.

I was thinking about a suitable recommendation for those who carry such an outlook.

There are how questions and why questions. In developing technology, we often become so embedded in the how that we imagine some kind of relevance sealed away from the real world, which demands us to ask why.

Why does Debian maintain its own separate package system? Is a technical reason satisfying, or is the reason primarily historic? Are upgrades isolated and reversible, or incremental and unidirectional? Are snapshots best handled through the file system, or through an abstracted file tree? Does Debian handle the full gamut of demands asked of modern operating systems, or prefer to stay confined to a more narrow niche? I think all such questions are broadly constructive.

For my part, I had assumed Debian users largely would want the system to evolve along a tract common with certain competitors, but now I understand the strength of devotion to certain classic characteristics. Yet, Debian is not just the Debian distribution, but also a larger family, including derivations. Of course, I understand when someone grows fond of a system, discussing major changes may be unpleasant. Debian in its current representation is hardly facing an immediate threat of disappearance, and those who like how it is now would gain more from expressing their own preferences, with respectfulness toward all, than from trying to silence every idea that is different.

However, to your point of encouraging discussion, I doubt any encouragement truly follows by relegating such threads to a section called "Offtopic". Perhaps another section might be added for the purpose, one with a more uplifting description, for example, "General Discussion". (In fact, although the thread was moved to "Offtopic", the description is given as "If it doesn't relate to Debian, but you still want to share it, please do it here". Based on descriptions alone, I tend to consider a better match to be the original location, "Development Discussion", or otherwise, "General Debian".)