Future and impact of ongoing projects in Linux world

[Xen]

JMZ schreef op 05-10-2016 7:50:
> Is there really a huge learning curve for .bashrc and xinit? .bashrc
> is mostly a way to make an alias list.
> 
> What I fear about snappy and other modularized systems is unnecessary
> complexity. I fear that simple commands such as tar -t are going to be
> replaced with a multiplicity of commands which may actually be more
> confusing in the terminal.  This complexity will take from terminal
> users and give to gui users.

I am not clear on why snappy would have anything to do with tar, unless 
you mean that we would use *other* commands to list the contents of 
archives, rather than tar?

I don't really also see why snappy or anything like it would be more GUI 
friendly? It might do more /for you/ in a way you don't want, and hence 
-- much like e.g. NetworkManager -- makes it easy for those who are okay 
with bad defaults.

That's the general problem I have also: more high level solutions but 
they are quite crappy compared to what you would do yourself. And 
because they are there, it is hard to get around them. They have not 
been thought out fully enough and now a complete solution exists that 
just sucks.

This makes it harder for other people who want to do the things 
themselves and want to do it right.

The problem is not the high level nature of it, but that the building 
stones are still incomplete and downright awful.

Main problems in Linux have not been solved and now big solutions are 
built on top of it, and the consequence is that those high level 
solutions must be as shabby as the low level underneath, but now a 1000 
fold worse, because you cannot get around it anymore.


SystemD has already addressed my needs but it is one of those solutions 
that is built on bad underneath, which is why it is so hard to use and 
like.

This is the contents of /usr/lib/systemd/user:

(On my system, currently):

basic.target                         gvfs-metadata.service               
  sockets.target
bluetooth.target                     gvfs-mtp-volume-monitor.service     
  sound.target
busnames.target                      gvfs-udisks2-volume-monitor.service 
  systemd-bus-proxyd.service
default.target                       obex.service                        
  systemd-bus-proxyd.socket
exit.target                          paths.target                        
  systemd-exit.service
glib-pacrunner.service               printer.target                      
  telepathy-gabble.service
gvfs-afc-volume-monitor.service      pulseaudio.service                  
  telepathy-salut.service
gvfs-daemon.service                  pulseaudio.socket                   
  timers.target
gvfs-goa-volume-monitor.service      shutdown.target
gvfs-gphoto2-volume-monitor.service  smartcard.target

All of the user services there are dbus except one, and it is disabled.

aug 27 22:45:12 xenpc systemd[4003]: Reached target Shutdown.
aug 27 22:45:12 xenpc systemd[4003]: Starting Exit the Session...
aug 27 22:45:12 xenpc systemd[4003]: Stopped target Default.
aug 27 22:45:12 xenpc systemd[4003]: Stopped target Basic System.
aug 27 22:45:12 xenpc systemd[4003]: Stopped target Paths.
aug 27 22:45:12 xenpc systemd[4003]: Stopped target Sockets.
aug 27 22:45:12 xenpc systemd[4003]: Stopped target Timers.
aug 27 22:45:12 xenpc systemd[4003]: Received SIGRTMIN+24 from PID 5286 
(kill).

This is the only log I can find (journalctl --user).

So the system is not actually getting used much, if at all.

(The above will get executed also for session close; this is not just 
reboots or system shutdowns).

Basically I should be able to put a service file in there and it will 
run (or one of the equivalent directories).