how much of puppy requires dbus?

[nosystemdthanks]

over my head, though with a bit of research maybe down the road i could pull a few rabbits out of my hat with that.

one thing ive found through the years is that even if i dont understand what im reviewing (as may be the situation here-- im not saying its a complete mystery though i wouldnt say i have a firm grasp of it either) just the details included make huge leaps possible-- fodder for the next search for an ideal solution.

in short: if this doesnt do it, it might make it several times easier to find something that will. thanks.

[technosaurus]

I had almost forgotten about nobus. I mainly did de-bus to help puppy devs build packages that wouldn't let you disable dbus via configuration - then I found nobus and pointed people to it since I didn't really want to maintain yet another package. Its actually easier for me to grep the source and modify it to make a patch, so I never really used it much myself.

There are now similar projects on github for pulseaudio, systemd, logind, udev, libevent, alsa, x11, xserver and glibc

I should add these to the unbloated coding resources.

[nosystemdthanks]

even if you can forget about kdbus and bus1 (which funnily enough, arent what bother me the most at all, thought kdbus should be) im really beginning to think that dbus should be #2 on the list of concerns along with systemd (for those who believe systemd is a problem) and while it may not be entirely practical to avoid dbus for everybody (it certainly seems like puppy users have it as more of an option than a requirement, thats cool) it seems like a good thing to opt out of when possible.

the attitude about infrastructure that is developing lately seems to be: "unless you can show that its malware or of exceptionally low quality, you should probably include it in your distribution/installation"

this goes against all security advice (dont install or run services you dont actually need, dont have a larger attack surface than necessary) but lately the gnu/linux world inspired/infested by red hat and free desktop seems to be more like windows:

* keep adding features until new hardware is required

* develop bolt-on security gimmicks (there are so many) to treat the problems we just made, instead of preventing them with good practices

* point to all the bolt-on nonsense just added and say "its state of the art, we dont know why these 'hobbyist distros' cant keep up but theyre clearly inferior."

this goes beyond marketing, its just furthering a culture that lies to everyone for profit. ok, i may have contradicted myself a little there.

im not sure how much we want dbus in our world. but im hardly concerned if we have it around sometimes. it should be more of an option and im impressed at the amount work done in this regard.

also, if most people had this attitude about dbus back when it was just dbus, i dont think systemd would be the default in debian today.

the real problem is that debian decided at one point that bloat was fine and that if its useful to anybody, then no amount of gratuitous interdependency is bloat or bad design.

that, and the political moves that put debians init modularity (and support of multiple kernels!) into check was extremely nasty and well-played.

this is still about dbus, but broadly its about the sort of problems that things like systemd and dbus (and freedesktop and enterprise lock-in-by-design) creates.

as far as i know, the overlap of lock-in and foss is mostly treated as mythological and unimportant-- while the problem continues to grow and the justification for the problem is:

"we cant have nice things if we dont model all our designs after enterprise solutions!"

by that logic, coupes and sedans (forget bicycles) should not exist. we should only have vans and trailers and cargo shipping containers and freight-class vehicles.

its both bleak and hilarious, and seems to affect puppy users very little because every time they find bloat they lop it off at all costs, without any sentimentality whatsoever.

[anikin]

My Devuan doesn't have dbus as shown in my previous post. There was no need for it when I built the system. If I ever need it in the future - one little command and dbus will get installed without a hitch.

Code: Select all

root@debian:~# apt-get update && apt-get install dbus
Get:1 http://auto.mirror.devuan.org/merged jessie InRelease [108 kB]
Get:2 http://auto.mirror.devuan.org/merged jessie-updates InRelease [119 kB]
Get:3 http://auto.mirror.devuan.org/merged jessie-security InRelease [106 kB]
Get:4 http://auto.mirror.devuan.org/merged jessie/main i386 Packages [6,809 kB]
Get:5 http://auto.mirror.devuan.org/merged jessie-updates/main i386 Packages [20.9 kB]
Get:6 http://auto.mirror.devuan.org/merged jessie-security/main i386 Packages [470 kB]
Fetched 7,634 kB in 10s (728 kB/s)                                             
Reading package lists... Done
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Suggested packages:
  dbus-x11
The following NEW packages will be installed:
  dbus
0 upgraded, 1 newly installed, 0 to remove and 205 not upgraded.
Need to get 311 kB of archives.
After this operation, 1,132 kB of additional disk space will be used.
Get:1 http://auto.mirror.devuan.org/merged jessie/main i386 dbus i386 1.8.20-1+devuan1.1 [311 kB]
Fetched 311 kB in 0s (376 kB/s)
Selecting previously unselected package dbus.
(Reading database ... 23815 files and directories currently installed.)
Preparing to unpack .../dbus_1.8.20-1+devuan1.1_i386.deb ...
Unpacking dbus (1.8.20-1+devuan1.1) ...
Setting up dbus (1.8.20-1+devuan1.1) ...
[ ok ] Starting system message bus: dbus.
root@debian:~#

Think of the power of Debian ...

[wiak]

Fetched 311 kB in 0s (376 kB/s)

Preparing to unpack .../dbus_1.8.20-1+devuan1.1_i386.deb ...

Wow... bloat...

Which happens to be a useful interprocess comms facility for people who program (create new programs)

[nosystemdthanks]

Which happens to be a useful interprocess comms facility for people who program (create new programs)

debatable. you can write any program and argue that it has a purpose and is thus useful, but if we are that forgiving then why not download windows and install it with every copy of puppy? (because, because, but really.)

that interprocess comms facility was written to replace what only gnome and kde needed, and the rest of the software world did alright without it. but as i paraphrased this swath of the software community:

if its useful to anybody, then no amount of gratuitous interdependency is bloat or bad design.

to which you said:

Which happens to be a useful interprocess comms facility for people who program (create new programs)

right, thats what i said someone would say.

and yet theres another side to that:

a heavyweight mechanism like D-Bus involving service discovery, an object system and authentication API does have consequences for a low-level userspace component compared to more primitive IPC.

Most other bus APIs then simply just deliver properties, usually just unit configuration information that could be sent through any mechanism, D-Bus offering no special benefits.

The ultimate irony then becomes that, one must communicate with an object system (D-Bus) in order to launch commands or query data which must be deserialized to another object system, all the while the real object system is obscured, non-uniform and hidden from user manipulation, though the proxy object system (D-Bus) nonetheless increasing overhead and failure paths of communication.

-- from https://blog.darknedgy.net/technology/2015/10/11/0/

or in other words: yes, bloat!

i mean if youre going to justify this sort of thing just on the basis that something hooks into it, we can pull a lot more garbage in, based on that thinking.

then there are others who have gone to the trouble of trimming the fat.

weve all had excesses here and there, this isnt about total purity or being saints or perfection of any sort. its a basic principle that if youve got too much nonsense you want the option at least, to trim it back.

that so-useful "interprocess communication" dohickey... oh geez, i just looked up the spelling of dohickey and to my astonishment... you cant make this up:

Software description: a hardware information program for gnome, using HAL to detect all available hardware and downloading required information from

puppy and freedesktop are practically at opposite ends of the spectrum. however, i ran kde from a pup in the days when that was still a commonly used package format and more people were still using the 2.x kernel and saying "do we really need the 3.x kernel version of puppy?"

and the one with the 2.x kernel would only support 10% of the usb sticks out there, but it just felt so speedy...

i think we would agree that at this point, the 3.x kernel is very much worth the "excess," but ive dropped kde and im using icewm now!

why? because even on a multi-core 64bit processor (in the days of 2.x puppy i was running a p4 and many lower machines, including a pii i believe) the resources that are used by the de/wm could go to something that really is useful.


https://l3net.wordpress.com/2013/03/17/ ... -desktops/

if we are honest, it depends who you ask-- every time. but if you make a habit of allowing every 2-bit "core operating system" thats posing as an init system, well, youre going to be shocked at the side-effects. vfat modules that dont work even when rmmoded modprobed after your debian 8 install until you reboot!

what operating system is that like? lenndows! noooo thank you! you can keep your ipc pos.

so can kate-- the text editor that (according to the dbus website itself) needs dbus!

ridiculous...

the icing on the cake though is that recently i had a system that (this never happened ever before) refused to open one more gui application because it "couldnt connect" to something (not sure it even said dbus)

for reasons i still havent determined, the process list was flooded from the basement to the penthouse with dbus-launch instances. i killed them from the term and was able to launch gui programs again.

i wasnt running a lot of gui programs, so my guess is that while trying to connect and reconnect to the network, wicd was spawning dbus-launch over and over and over. maybe wicd wont even spawn dbus-launch. maybe i should run an av scanner on that machine. maybe its aliens trying to make contact with us using ipc...

its not typical at all, but in 10+ years of gnu/linux its one of the funniest things ive ever witnessed. systemd isnt an init, freedesktop in general is becoming a miniature implementation of windows to include in every debian/fedora/arch install.

systemd is its largest dongle, and dbus seems like one of its minions. the behaviour of dbus-launch happens to be one of the most windows-like things ive encountered. its a crap.

you do know that quite a few of us switched to get away from this sort of thing? i mean its far from the only reason to use gnu/linux, but quite a few of us are here for that aspect of it. we dont need it reimplemented for windows-style programmers, it really isnt necessary for us users. (i use python, and there are headers for dbus but its highly unlikely i will ever use those.)

[rufwoof]

its not typical at all, but in 10+ years of gnu/linux its one of the funniest things ive ever witnessed. systemd isnt an init

Linux is fundamentally just the kernel. Debian have done a great job of expanding that ... security of a single provider for all code (anything else is a FrankenDebian), wrapped around a kernel. That goes a long way to make a complete all-in-one 'package' (security and delivery). SystemD is a init, modularised so you don't get the timing conflicts and/or having to write sleep's into the structure to try and get things to operate as intended, but that sometimes even then still sequences in the wrong order.

OpenBSD is a similar all-in-one, kernel equivalent and X etc all in a single package and init style based, but where whilst that is usable in isolation it is limited (http server, X, wm, basic calculator, editor ...etc.).

Of the two I suspect systemD will win out. For one there are fewer developers/maintainers in the next generation of school leavers. Mostly a Generation-X 'hobby' whilst Millennial's are more inclined to the alternatives (smart phones ..etc.). Of the two however I personally prefer the init side of things. More fun. But as the X generation fade, so IMO will init. Bloat in a world where the phone in you pocket has massive amounts of capacity/power and continues to increase year on year is a relative thing. For end users anything else is potentially redundant, but continues to have a following for fun purposes, at least at the 'user' level.

My (adult) millennial 'kids' consider a desktop pc to be bloat, after all they can vocalise a google search request into a small hand held device (their phone) and have the answer quicker than I can type entry a google search, and I type relatively quickly. All a matter of perception, and what feels like fun.

[8Geee]

I <3 that chart... JWM very small LXDE and XFCE large. And I can reconfigure a theme by altering its jpg/png files with mtpaint and have a new theme. Thanx 4 that.

8Geee

[nosystemdthanks]

Linux is fundamentally just the kernel. Debian have done a great job of expanding that ... security of a single provider for all code (anything else is a FrankenDebian), wrapped around a kernel.

youve gone straight from kernel to distro, which is a peculiar trajectory but id agree with most of that (certainly not the "frankendebian" line. my goodness, youre implying that debian proper has de facto greater security than some debian derivatives...) if not for the path debian has taken recently.

also even if youre correct for the most part (and you probably are) it doesnt negate any of the exceptions to your rule. debians "great job" might really be lacking in a few spots, and i certainly think so.

That goes a long way to make a complete all-in-one 'package' (security and delivery). SystemD is a init, modularised

if you really want to rehash a heavily-disputed debate here thats fine, i mean its my fault as much as anybody elses that we are shifting from specifics like dbus to the broader issue of systemd and freedesktop (its difficult not to.)

but systemd is NOT an init! thats like saying someones going around selling camel noses, and if you want to buy one theres a portable mounting device (we call this a "camel") which will help keep the nose in place near the opening of your tent. but really, ITS JUST A NOSE! https://en.wikipedia.org/wiki/Camel%27s_nose

so you don't get the timing conflicts and/or having to write sleep's into the structure to try and get things to operate as intended, but that sometimes even then still sequences in the wrong order.

yeah, no... i am very familiar with this argument and first read it three years ago, but no, it holds less water each year that goes by.

the biggest fallacy systemd presents us with is that by using new-fangled (but arguably and definitely sometimes superior) technologies it its implementation, it is ITSELF better-designed.

but in practice systemd is just as much like the guys that add "horsepower" to their car with decals and spoilers--

it implements things with containers and sockets to do things that other container and socket-based software can arguably do better.

it implements concurrency in ways that other concurrency-based things can arguably do better.

it avoids simple timing conflicts in a highly-convoluted fashion all to eliminate a problem it actually retains (systemd also sequences things in the wrong order sometimes, only now it claims this is impossible by virtue of its design)

and in the process, it ties together every component that it can get its hands on (depends who you ask, but this is certainly and remains arguable.)

but what do i know? i mean some of this im only paraphrasing ian jackson, one of the original debian developers who said these things three years ago and is still fighting systemd today.

if you want ian jackson quotes about this, i collect them... hes hardly alone in these proclamations...

OpenBSD is a similar all-in-one, kernel equivalent and X etc all in a single package

are your fingertips burning? im surprised you can make that comparison and you dont just explode like the desk guy in monty python. i mean this is in jest, but the shock is very close to sincere...

Of the two I suspect systemD will win out. For one there are fewer developers/maintainers in the next generation of school leavers. Mostly a Generation-X 'hobby' whilst Millennial's are more inclined to the alternatives (smart phones ..etc.).

if i took you seriously about this, id probably want to kill myself. youre resigned to a festering pile of os, but i am not and theres far too much being done to mitigate or cure this to stay depressed.

Of the two however I personally prefer the init side of things. More fun. But as the X generation fade, so IMO will init. Bloat in a world where the phone in you pocket has massive amounts of capacity/power and continues to increase year on year is a relative thing.

its really not though, because i could spend the next hour talking about all the times that we are sitting in front of a modern machine going

COME ON!
COME ON!
WTF!!!!!!

and we are waiting for something that was INSTANTANEOUS on older hardware.

and the freaking absurd arguments people make for why we dont understand that we need all these things that half the speed of every core we add to the cpu...

its all an obscenity, and *we* are the last bastion against it.

no! thats not fair-- bsd is. im not going to count minix and freedos, ok?

im astonished by your cynicism, though youre entitled to your opinion like everyone else-- and tech industry shills are all on your side of the argument. thats nearly like a pre-win!

For end users anything else is potentially redundant, but continues to have a following for fun purposes, at least at the 'user' level.

i particularly hate this form of reasoning. i was an end user to begin with. if i have no reason to care about this stuff as an end user... and i care about it now, it stands to reason that we dont actually know what end users will care about and any statements about redundancy are specious.

but i knew that already.

My (adult) millennial 'kids' consider a desktop pc to be bloat, after all they can vocalise a google search request into a small hand held device (their phone) and have the answer quicker than I can type entry a google search

thats *really* not what bloat means. if i say bloat im sure you understand the meaning, what youre doing is making a comparison of something else *to* bloat, and telling me your kids dont know the difference. its not a crime, its just a bizarre and inaccurate use of the term. cue the ongoing debate about language evolving and im on the "let it evolve" side of that, but even i think this is a specious use of the term...

i mean im all for language evolving, but i wouldnt use humpty dumpty's collegiate edition.

All a matter of perception, and what feels like fun.

i dont reduce all philosophy, design, ethics, and ideals to "all a matter of perception and what feels like fun" and i dont believe you do, either.

still, its an interesting conversation!

[s243a]

I don't think that this thread is the place to debate systemd or dbus for that matter. Let users decide for themselves. I do know though that whenever I install a package that installs a bunch of systemd dependencies I uninstall it. I'm also suspicious of gnome dependencies. For puppy these things are just bloat.

Regarding dbus I use it because debian/ubuntu builds of firefox require it. Although I don't know if palemoon does and I don't always install firefox.

I notice that someone above has a version of Devuan without dbus. It would be cool if someone tried building a puppy based on this.

On another note, what does dbus buy us that we can't do with named pipes or TCP sockets? I'm not saying that dbus isn't great, I just have no idea what it offers.

[wiak]

Which happens to be a useful interprocess comms facility for people who program (create new programs)

...

Which happens to be a useful interprocess comms facility for people who program (create new programs)

right, thats what i said someone would say.
...
you do know that quite a few of us switched to get away from this sort of thing? i mean its far from the only reason to use gnu/linux, but quite a few of us are here for that aspect of it. we dont need it reimplemented for windows-style programmers, it really isnt necessary for us users. (i use python, and there are headers for dbus but its highly unlikely i will ever use those.)

I've never programmed in Windows actually, and started using Linux in 1991 or 2 when I was a postgrad and it came in a couple of dozen floppy discs; there was no commercial Internet then, but most of my programming back then was with Solaris (UNIX), writing Inter Process Comms client server apps (very basic raw system-call level and tcp/ip socket based programming in guess... C) whilst experimenting in improving performance of TCP/IP over long-delay noisy satellite link communication networks; really nothing to do with Windows!

Long time ago though

https://ieeexplore.ieee.org/document/266145/

A lot more recently (oh, it was 2008 in Linux) I also implemented a primitive SysV message queue based IPC for Linux that could be used from bash (which has no such IPC facility other than named pipes). Oh these basic systems work, and of course they are efficient, but what a nightmare to manage all such client/server comms... most apps do not need lightning speed efficiency - and programmers want to concentrate on their app-building and not have to concern themselves with system-level C programming of individual IPC mechanisms. What is needed is a higher-level interface with a consistent API - oh... that's what the likes of Dbus provides.

But yes, use what you like and feel comfortable with. Don't expect Linux to keep using old IPC mechanisms from half a century ago forever though. Systems inevitably get more complex, even individual apps - that's not bloat per se, that's a result of increasing speed, power, complexity, capability - it's the result of research, progress, and development that gradually filters its way down to non-tech users. But by all means use old Red Hat 5.1 or something and avoid newer apps altogether if you can for as long as you can. Sad, I know. Or just make smoke or use flags to communicate rather than all this bloat called 'computers'.

wiak

[technosaurus]

On another note, what does dbus buy us that we can't do with named pipes or TCP sockets? I'm not saying that dbus isn't great, I just have no idea what it offers.

Not much, see ubus Geany uses unix domain sockets IIRC. Its just convenient to have _some_ protocol with a well-defined specification, no matter how inefficient it is. Once something gets >10% adoption, its hard to replace (see windows and x86) unless its just extremely better and lets be honest most dbus messages are infrequent and less than Linux's PAGE_SIZE, so it doesn't really need to be good.

[wiak]

Indeed. But were it not for 'well defined specifications' and APIs, most of what we have now would still be just ideas in peoples heads. Formal specifications is what created the Internet by the way. Of course, worse of all is proprietary protocols and specifications - everyone doing their own thing and unable to cooperate with each others mechanism. Of course Dbus is not tiny, superfast, like socket comms - its a high level interface that can be used without having to worry about the underlying implementations - all such higher layer stuff relies on consistent specification/APIs. Research and development is not at all about making tiniest Linux systems possible - but that's a fine 'hobby'.

Domain sockets are certainly very basic, and simple, but also limiting to their purpose, which is narrow. An abstracted comms system can use all sorts of underlying mechanisms, giving it great power, without the programmer needing to implement every part of what it can handle (which simply would take too much reinventing and effort). TCP/IP stack is of course itself a complex layered system with much complexity (such as raw and udp and tcp socket handling sitting down beneath - and often not needing to concern the application programmer but instead accessing these lower layers through some abstraction or other (hopefully a formalised one so re-usable...)

Fact is, dbus isn't actually a huge system. You can certainly use basic IPC mechanisms, such as various socket types or pipes, and forget about dbus and turn off services that use it. Larger system designs need something like dbus though, so I'm quite sure it won't go away, and nor will pulseaudio, and nor will systemd - not until of if someone comes up with some alternatives (which will do much the same thing and probably more). Browsers don't just browse anymore - lots of protocols being used in there, lots of processes communicating with each other - not so much a speed issue for much of these comms, so far easier to use higher-level API to something like dbus than to implement all process comms down at system socket level.

wiak

[nosystemdthanks]

I don't think that this thread is the place to debate systemd or dbus for that matter. Let users decide for themselves.

this as interesting string of words because of its trajectory-- i agree with you about whether making the topic broader to include systemd is a great idea (its not, i did it anyway, it wasnt a great idea though-- theres already a systemd thread here with 350+ posts) and you say "or dbus for that matter."

well the thread is about dbus, and i started it and it served its purpose (i got the information i was looking for and better yet, i got some opinions i was looking for-- on both sides of a debate perhaps.)

so unless this is about which subforum is best (i will yield to that if necessary, but i doubt it will result in anything) i dont know why we wouldnt debate the merits of dbus in "this thread." seems like the most reasonable place to me.

then you say:

"Let users decide for themselves."

well, they already do. im not editing the puppy linux roadmap here, i have no control over that.

in fact my question was specifically about puppy, whereas for me the debate is not-- for me the debate about dbus is broader and i *honestly* really truly dont care whether puppy has it or not, i only asked to help me with my picture of how it fits into (or is avoided by) each distro.

i was really just looking for a data point, which i got.

im not advocating that puppy go more dbus free than it is (i think its terribly unlikely) but in general (all distros) i think its worth considering. if that sounds like a contradiction, i get it.

I do know though that whenever I install a package that installs a bunch of systemd dependencies I uninstall it. I'm also suspicious of gnome dependencies. For puppy these things are just bloat.

i agree and suspect we are right about this.

Regarding dbus I use it because debian/ubuntu builds of firefox require it. Although I don't know if palemoon does and I don't always install firefox.

i have gained another data point. i would point out (it could be relevant) that firefox tends to require pulseaudio these days, and pulseaudio comes from the same freedesktop group as systemd and dbus, so its not unreasonable to assume they could be related.

if you remove the pulseaudio dependency you might lose the dbus dependency. but this is pure speculation.

I notice that someone above has a version of Devuan without dbus. It would be cool if someone tried building a puppy based on this.

in terms of this thread continuing, thats gold right there. thank you, i will spread word of this.

On another note, what does dbus buy us that we can't do with named pipes or TCP sockets? I'm not saying that dbus isn't great, I just have no idea what it offers.

it offers ipc. it offers ipc in a way that is enticing to kde and gnome devs, and a lot of the things that require dbus are part of gnome or kde or freedesktop. avahi and cups require dbus, usually. avahi was written by lennart poettering and cups may require it or not, i dont know if cups would need it if avahi didnt.

wiak has stated twice the advantages of having ipc, and (sadly) dbus is the de facto standard for this (as far as i know) in the free software world, but thats partly due to the aggressive promotion / excessive interdependency of freedesktop / red hat and their designs in general. this isnt speculation, one of their ceos actually hinted at it pretty blatantly. they didnt get to be a billion dollar corporation on sheer meritocracy.

i do not dispute the value of ipc (as i said,) and so i dont consider it a proper explanation of why we really need dbus.

dbus has flaws, some in the sense of lock-in and other in the resource costly and sometimes very buggy way that it implements ipc. when you consider those factors, i think the comparison to windows is completely warranted.

worse, i really believe at this point that freedesktop is probably creating a gnu/linux replacement, NOT gnu/linux components.

thats fine, if its an alternative. but the way theyre doing it is gutting the operating system infrastructure along the way, so its not an alternative at all.

its like a parasitic wasp gnu/linux replacement. red hat may not be purely evil, but theyre at least as bad as google or microsoft and theyre creating increasing amounts of lock-in using microsoft tactics, while gutting our alternatives.

theres a broad community here, with different values and different goals. but for some of us at least, this goes against everything we stand for. i know that iguleder at least,

(is he the one with the dbus-free devuan? because the shoe fits! someone compared me to iguleder recently and i was incredibly flattered)

created librepup and this goes against everything he stands for.

i used to know his irc handle and i dont know if he is still involved with puppy. but if anybody finds iguleder around here, please let me know. ill have a look for his puppy username / profile (its "iguleder") in a moment.

let me acknowledge (reading the part about 1991) that even if i disagree with wiak on this, he obviously has serious chops and im closer to that of a journalist and hobby coder than kernel developer. he can make heavier technical arguments-- and i can quote disputes of those arguments. so its a bit like im fighting this with a single arm, because i just never got the other one.

that doesnt give me a whole lot of confidence that i will find myself on his side of the argument though. there are certainly qualified people on both sides of this.

[wiak]

Well, I personally much prefer system level programming and I find smallest usable, fastest, lowest RAM and CPU using distributions fascinating - almost like a challenge to squeeze as much as possible out of a system. However... whether a dbus, or systemd or systemd_incorporating_dbus, or pulseaudio or systemd_incorporating_pulse audio is a good idea or not, I do think integration and standard specifications are the way forward in the development of any system - and the world does not and will not stand still. So to me, the argument is not about what is best (I don't consider myself at all able to answer that - those who develop the likes of systemd are the ones with the experience and talent - I don't for a second believe it is all RedHat clout and politics - these developers are talented despite the scorn some pour on them via some quote or another). I do wonder if the days of OS fitting on CDROM are almost over; the Internet is becoming the main application driver (inevitably) and browsers simply mirror that complexity. Without a browser able to partake in that expanding Internet universe, a small simple distribution isn't going to be much use to anyone. Puppy seemed to give up much of its 'smallness mantle' when it adopted Debian/Ubuntu repositories for some of its productions - yes they left out systemd and pulseaudio (the omission of the latter becoming quite a pain sometimes). DebianDog came out in the size of Puppy and could run anything... Slitaz is a wonderful fast toy - tinycore linux similarly, but always was for the enthusiasm nitty-gritty build hobbyist - lots of work... Most of the general public just want to use their computers to partake in the tech universe the broadband Internet provides them. I am not saying I love the way the world is changing - ham radio was far more interesting - but in ten years time no-one will bother asking if dbus or systemd or pulseaudio (or any future replacement of these) should be taken out of Puppy - they or similar will be there or Puppy will not exist aside for a toy no one alive on the Internet will actually use. But that's just my opinion - nothing to do with having any 'serious chops' - I'm long retired and just playing at computers for my own amusement and perhaps to keep my brain a bit alive - but not a day goes by now that I do not think enough is enough. Anyway, we will see what happens so I'll just wait for that.

wiak

[wiak]

But there is hope. Analogue (analog..) design was my original field. But the Karnaugh Maps, the Boolean, crept in, and then I found myself programming Z80 microprocessors to do what a single transistor with R/C network could already do (somewhat imperfectly)...

http://www.bbc.com/future/story/2018042 ... ll-endures

I once built an analogue 'computer' with potentiometers and op-amps - it was very complex and could compute the most simple things and talk to the world via some torch bulbs. Such machines became only seen in the museum (though helped take the Apollo's to the Moon) as does the Acorn Atom and BBC and Atari and Commodore 'Pets' of the low-RAM/Resources/CPU-speed not-so-distant-past (along with the IBM 'compatible' 8088-based computers that had a 640 kB architectural limit - had a nice wordprocess, spreadsheet and... AutoCAD software running on it back then, so not exactly caveman style - did I mention 'ATARI, and APPLE 1' - Puppy is so bloated comparatively, so I do understand all the concern).

wiak

[greengeek]

Great conversation. Just for clarity - are you looking for a puppy that does not need dbus?

If so - what hardware (Brand, year of manufacture, ram size and number of cores)

cheers!

[greengeek]

I once built an analogue 'computer' with potentiometers and op-amps - it was very complex and could compute the most simple things and talk to the world via some torch bulbs.

Jeez, Wayne! please come visit me if you are ever in the southern hemisphere.

I mourn the move from analog comms (fax) to monitored digital comms (isp derived priority controlled internet access).

Analog rules!

Vive la steampunk! (to - somewhat inaccurately - quote the french)

[nosystemdthanks]

greengeek, there are broader reasons i ask than personal use, but just to give you an idea:

* i have a distro based on refracta/devuan/debian that used to mix those with puppy:


[ mtpaint-edited boot screen from tahr ]

boot: puppy
[ librepup mixed with some updated binaries from refracta starts ]

boot: live
[ refracta mixed with some barry kauler binaries from librepup starts ]

due to lack of interest i dropped the librepup side but (until recently) kept petget and some librepup icons (and the proper license information!) in the refracta side.


i remaster with full automation, so no clicking and no repeating, just run the script and the .iso is produced.

woof-ce is inspirational though.

this is not just about research on how to remove dbus from my distro (low priority)


i am also trying to create a nexus of systemd-free developers (hating systemd not necessary. interest in removing it or making it optional and contributing knowledge around those goals is useful either way)

...across several distros.

puppy is actually great in this regard, as a data point / example / community research hub.

no joke. people struggle with this elsewhere, people here do it for giggles.

even if its not as funny as it used to be.

just to be clear, when i go to the trouble of doing something, i usually have a list of reasons. just one reason? ill wait...

cheers.