Possible removal of pup_event_ipc.bac

[wdlkmpx]

I have never used it, and don't plan to use it. I'm not going to translate it to C either.

Has anyone ever used it?

https://github.com/puppylinux-woof-CE/woof-CE/blob/testing/woof-code/rootfs-skeleton/usr/local/pup_event/pup_event_ipc-README.htm

there is also code in pup_event_frontend_d that interacts with the ipc // also post block-drive events to any ipc client... // look for any files named /tmp/pup_eventipc/block* ...

i did test this while testing the C version, and to be honest, it looks pointless..

[mavrothal]

I think tis was an old attempt for a dbus alternative but never used for anything...

[wdlkmpx]

I'm sure we can find something more elaborate if we really want a lightweight dbus alternative in rootfs. By removing this, it's also easier to replace pup_event_frontend_d with something else.

[mavrothal]

Everything can be replaced with something else but why? does it solve an issue? adds a new feature? Just makes puppy more conventional? Other?

[wdlkmpx]

More conventional is the word, by simplifying the hardcoded stuff and making more conventional, it actually makes it easier to understand for everyone. Otherwise i don't think people will be able to contribute. I'm not an it person, but i happen to understand quickly all this stuff, but that doesn't apply to the other 98% of users. the other 2% is not interested in contributing because all the simplifications never happened..

Making it more conventional also means applying the same settings but with other backend with some minor tweaks.

That's why

[wdlkmpx]

My intention is not to turn the pup_event stuff into something else.

If i get to do what i want, in fact it will work exactly the same, but faster and with less options (DESKICON = ICONPARTITIONS and labels probably).

It's just udev based stuff that happens to do unorthodox stuff to get the info. It's simple, udevd stops working = pup_event_frontend_d does not get any events.

At this point, puppy depends completely on udev.

The real problem is how unorthodox is puppy, and how many core code lines are actually part of a desktop that is unlike all the others and few really want to use.

The hipster syndrome..

[mavrothal]

It is true that around udev-151 pup_event surrendered to udev. The "problem" is that udev is integrating with systemd and if eudev stops functioning as expected, things may become difficult. The whole idea of pup_event (_ipc etc) is to provide an alternative infrastructure. Never worked to that extend, but is the idea that counts 😄 Uniformity can be good for contributions, though usually it favours big organisations. To avoid obscurity you need a niche 😉 Anyway, the important part is to have fun. If you do, go for it! Just try a bit better commit messages, and not "multi functional" commits (specially those that is 200 lines editorial and 3 lines code change) because at the end you'll be the only one knowing what is happening with puppy 😈

[wdlkmpx]

Well, actually the way puppy is designed makes it way more difficult. When I'm on Windows i'm just a regular user, but when i use puppy, I have to put on my robe and wizard hat and cast wisdom level 9001. And things improve.

The scripts are actually quite complex and convoluted, it really takes talent to improve them, the rational mind would rewrite the whole thing with a different approach.

The truth is that improving stuff in puppy, specifically everything directly depending on the rox desktop and the custom categories is like carrying a dead body.. a corpse. I must admit that i'm a masochist, because i hate rox but i still improve the scripts related to it.

In fact i found that everything is easier to set up without rox, such as some lxde apps + pup-volume-monitor, in the 'w' branch i achieved success with a non-root user, while the rox stuff was still buggy as hell. Making the rox stuff completely optional in the build process and scripts is the least that can be done.

Well regarding udev and systemd, i believe the death threats against Poettering were justified and i doubt gentoo will stop supporting the alternative udev in the foreseeable future.

Which reminds me, i had the idea to add a new compat distro: alpine linux, and the like, which don't use systemd at all, i wrote a few lines to support pkgs, but it;s stalled since january 2017 maybe