Puppy Linux Discussion Forum Forum Index Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Thu 27 Nov 2014, 01:51
All times are UTC - 4
 Forum index » Taking the Puppy out for a walk » Announcements
boycott systemd
Moderators: Flash, Ian, JohnMurga
Post_new_topic   Reply_to_topic View_previous_topic :: View_next_topic
Page 2 of 10 Posts_count   Goto page: Previous 1, 2, 3, 4, ..., 8, 9, 10 Next
Author Message
Karl Godt


Joined: 20 Jun 2010
Posts: 3972
Location: Kiel,Germany

PostPosted: Tue 06 May 2014, 12:13    Post_subject:  

Have nothing brings nothing .

Money is generated if you can tell the bank about something new .
systemd is something new .

Let's face it : Manpower is recruited with money from a bank .
Someone must take a step forward and make Puppy commercial with an openPUPPY branch .

That needs focusing on few hardware setups or machines and kernels that are optimized for these hardwares and they likely would not have the drivers for other setups .

And it needs a headquarter where the developers open a door each day and not some windows .
Since the few developers are scattered all over the world this is currently difficult to enable or not possible .

I for myself only own a crappy eeepc to introduce at a bank .
No laptops in sight .

Main suggestion would be to rewrite *dialog* applications in GTK, since
*dialog* apps are for short dialogs and not for sophisticated GUIs .
Main problem I have with gtkdialog is that the GUI needs to be rebuild completely if variables change .
Back to top
View user's profile Send_private_message Visit_website 
mavrothal


Joined: 24 Aug 2009
Posts: 1806

PostPosted: Tue 06 May 2014, 12:16    Post_subject:  

jamesbond wrote:
perhaps the kernel will be merged to become part of systemd, too Shocked

Isn't it time for a BSD puppy? Laughing

_________________
Kids all over the world go around with an XO laptop. They deserve one puppy (or many) too Very Happy
Back to top
View user's profile Send_private_message 
Iguleder


Joined: 11 Aug 2009
Posts: 1924
Location: Israel, somewhere in the beautiful desert

PostPosted: Tue 06 May 2014, 17:22    Post_subject:  

Here's my init:

Code:
#include <stdlib.h>
#include <string.h>
#include <stdbool.h>
#include <signal.h>
#include <sys/types.h>
#include <sys/wait.h>
#include <unistd.h>
#include <sys/reboot.h>

/* the init script path */
#define INIT_SCRIPT_PATH CONF_DIR"/rc.d/rc.sysinit"

/* the shutdown script path */
#define SHUTDOWN_SCRIPT_PATH CONF_DIR"/rc.d/rc.shutdown"

#define PRINT(x) (void) write(STDOUT_FILENO, x, sizeof(x))

void _signal_handler(int type, siginfo_t *info, void *context) {
   (void) waitpid(info->si_pid, NULL, WNOHANG);
}

bool _run_script(const char *path, pid_t *pid) {
   /* the return value */
   bool is_success = false;

   /* the process ID */
   pid_t parent_pid;

   /* the process signal mask */
   sigset_t signal_mask;

   /* get the process ID */
   parent_pid = getpid();

   /* empty the signal mask */
   if (-1 == sigemptyset(&signal_mask))
      goto end;

   /* create a child process */
   *pid = fork();
   switch (*pid) {
      case (-1):
         goto end;

      case (0):
         /* reset the child process signal mask */
         if (-1 == sigprocmask(SIG_SETMASK, &signal_mask, NULL))
            goto end;

         /* in the child process, run the init script */
         (void) execl(path, path, (char *) NULL);

         /* upon failure, send a signal to the parent process */
         (void) kill(parent_pid, SIGTERM);

         break;

      default:
         is_success = true;
         break;
   }

end:
   return is_success;
}

int main() {
   /* the process exit code */
   int exit_code = EXIT_FAILURE;

   /* a signal action */
   struct sigaction signal_action;

   /* a signal mask used for waiting */
   sigset_t signal_mask;

   /* the init script PID */
   pid_t script_pid;

   /* the signal received */
   siginfo_t received_signal;

   /* the command passed to reboot() */
   int reboot_command;

   /* assign a signal handler for SIGCHLD, which destroys zombie processes */
   signal_action.sa_flags = SA_SIGINFO;
   signal_action.sa_sigaction = _signal_handler;
   if (-1 == sigemptyset(&signal_action.sa_mask))
      goto end;
   if (-1 == sigaction(SIGCHLD, &signal_action, NULL))
      goto end;

   /* block SIGUSR1 and SIGUSR2 signals */
   (void) memcpy(&signal_mask, &signal_action.sa_mask, sizeof(signal_mask));
   if (-1 == sigaddset(&signal_mask, SIGUSR1))
      goto end;
   if (-1 == sigaddset(&signal_mask, SIGUSR2))
      goto end;
   if (-1 == sigprocmask(SIG_SETMASK, &signal_mask, NULL))
      goto end;

   /* run the init script */
   if (false == _run_script(INIT_SCRIPT_PATH, &script_pid))
      goto end;

   /* wait until either SIGUSR1 or SIGUSR2 is received */
   if (0 == sigwaitinfo(&signal_mask, &received_signal)) {
      if (script_pid != received_signal.si_pid)
         exit_code = EXIT_SUCCESS;
   }

   /* ask all processes to terminate */
   PRINT("Terminating all processes\n");
   if (0 == kill(-1, SIGTERM)) {

      /* upon success, give them 2 seconds and kill them brutally */
      (void) sleep(2);
      (void) kill(-1, SIGKILL);
   }

   /* disable the SIGCHLD signal handler, to make it possible to wait for the
    * shutdown script to terminate */
   if (-1 == sigemptyset(&signal_action.sa_mask))
      goto flush;
   signal_action.sa_flags = 0;
   signal_action.sa_handler = SIG_IGN;
   if (-1 == sigaction(SIGCHLD, &signal_action, NULL))
      goto flush;

   /* run the shutdown script */
   PRINT("Running the shutdown script\n");
   if (true == _run_script(SHUTDOWN_SCRIPT_PATH, &script_pid)) {

      /* wait for the shutdown script to terminate */
      (void) waitpid(script_pid, NULL, 0);
   }

flush:
   /* flush all file systems */
   PRINT("Flushing file system buffers\n");
   sync();

   /* reboot or shut down the system */
   switch (received_signal.si_signo) {
      case SIGUSR1:
         PRINT("Shutting down\n");
         reboot_command = RB_POWER_OFF;
         break;

      case SIGUSR2:
         PRINT("Rebooting\n");
         reboot_command = RB_AUTOBOOT;
         break;

      default:
         goto end;
   }
   (void) reboot(reboot_command);

end:
   return exit_code;
}


Believe it or not, Puppy works just fine with this one, with a minor modification - initNEW should run 'cttyhack init' instead of just 'init'.

_________________
My homepage
Back to top
View user's profile Send_private_message Visit_website MSNM 
ICQ 
bark_bark_bark

Joined: 05 Jun 2012
Posts: 900
Location: USA

PostPosted: Tue 06 May 2014, 17:40    Post_subject:  

I think linus has no intentions of allowing systemd to take over the kernel.

EDIT: Edited because the (relevent) above post was removed.

_________________
......

Edited_time_total
Back to top
View user's profile Send_private_message 
gcmartin

Joined: 14 Oct 2005
Posts: 4444
Location: Earth

PostPosted: Tue 06 May 2014, 19:10    Post_subject:  

Not to be taken wrongly as I have NO particular position. I remain a "simple" user. But the Linux "boards" are a bastion of world Linux experts, hardware manufactures, OS development corps and users. It takes a long time before ANYTHING in Linux gets done. Then it takes years of nail-biting to get the Linux world to come around because of all the differing personalities that stake a position. Yes, its normal, I know and it has both positives and negatives in doing so.

But, we are Puppy LInux with some very smart talents.

Here's a view. Is there a way for some of the distro developers to begin approaching this such that anyone, a builder, can select which they will use in system starts and operation?

We have seen the same thing occur in discussion of EFI, yet the world of manufacturers and vendors have continued that trek.

We will have little influence in changing the world trek, unless we join the boards where we make acceptable contributions in the discussion of the pros/cons in the directions they take.

But, in this domain, we can observe and take advantage of whatever offerings they make available such that we BENEFIT from those offerings without shooting ourselves in continual future tweaks.

If we boycott, is it because we hate change, or has the world produced a new approach planning a follow-on that we should wait for? And what do we gain or lose from a boycott? Gentoo, has a radically different mindset that they approach Linux from. Its a good one, but its different. While most other distros have some commonality.

Gotta love the Linux OS. But, like any OS, it changes causes major upheavals. This has been seen over the history of time with Apple, Microsoft, IBM, Canonical, Intel, AMD, etc. It will continue at the developer user levels, but it wont stop the marches just as it did not stop the march to 64bit. or to WYSIWYG (as in Windows/Apple/X desktops) or touch (as you see in every handheld) or ....

@JamesBond and others are correct in contemplating the development impacts that they show.

If there's a better way, or a replacement that can be developed in Puppyland, then let's do it and "offer it to the wider Linux community, as well as the IT Unix community" for scutiny and guidance.

_________________
Get ACTIVE Create Circles; Do those good things which benefit people's needs!
We are all related ... Its time to show that we know this!
3 Different Puppy Search Engine or use DogPile
Back to top
View user's profile Send_private_message 
anikin

Joined: 10 May 2012
Posts: 529

PostPosted: Wed 07 May 2014, 08:22    Post_subject:  

The devil isn't as black as painted. Before subscribing to the boycott, it won't hurt to have a look at the other side's views.
Lennart Poettering wrote:
But first, let's clear a few things up: is this kind of logic new? No, it certainly is not. The most prominent system that works like this is Apple's launchd system: on MacOS the listening of the sockets is pulled out of all daemons and done by launchd. The services themselves hence can all start up in parallel and dependencies need not to be configured for them. And that is actually a really ingenious design, and the primary reason why MacOS manages to provide the fantastic boot-up times it provides. I can highly recommend this video https://www.youtube.com/watch?v=SjrtySM9Dns where the launchd folks explain what they are doing. Unfortunately this idea never really took on outside of the Apple camp

https://freedesktop.org/www/Software/systemd/
http://0pointer.de/blog/projects/why.html
http://0pointer.de/blog/projects/systemd.html
http://0pointer.de/blog/projects/the-biggest-myths.html

To my layman's reason, the logic behind the boycott is akin to saying "boycott fuel injection, becuase it threatens our carburetors." The only impact I can think of is that we noobs - brave mouse-pushers, like myself and gcmartin, will have to do a lot of reading. Not only to understand what systemd is, bot what it's designed to replace in the first place.
Back to top
View user's profile Send_private_message 
bark_bark_bark

Joined: 05 Jun 2012
Posts: 900
Location: USA

PostPosted: Wed 07 May 2014, 08:28    Post_subject:  

let's not forget why systemd is bad here. systemd is a tool for RHEL developers to establish a monopoly.
_________________
......
Back to top
View user's profile Send_private_message 
gcmartin

Joined: 14 Oct 2005
Posts: 4444
Location: Earth

PostPosted: Wed 07 May 2014, 15:15    Post_subject:  

I not convinced that the industry is RedHat. It appears that Microsoft and Apple and Intel and AMD and ... have contributed.

Why is the Unix/Linux industry, now, RedHat?

I just recently booted an Alpha7 in a KVM guest that has, to my surprise, systemd built in. I am NOT suggesting anyone, here, do anything beyond what they feel is right. But, seems some distro developers in the Linux industry are moving. I wonder if their decision was to some benefit they perceived or for a greater understanding for what they envision for their future?

Personally, again, I have NO concern as either way, for me, my needs are at the subsystem-application levels. So, I am only trying to offer some ideas, just as others are presenting for a rational approach that will benefit Puppy distro developers as we march into its future. Same as was done with WOOF-CE as it presents a platform for good solid future life in Puppyland.

This will be my last post, here, because I am not a device developer or a system developer (was long ago). Systems developer ease and certainly simple easy to understand and use future needs would be a good review. Or create a brand-new model and present to Linux industry while we maintain and use such in Puppyland as a working model for industry review. Otherwise, we can weigh its beneficial side and use what would help Puppy slide into the future...just as we do when we use EFI, debian, slackware, Citrix, RHEL, and the many other ideas and products found in Open Source Community and certainly in Linux and used to make good/better Pups.

Here to help

_________________
Get ACTIVE Create Circles; Do those good things which benefit people's needs!
We are all related ... Its time to show that we know this!
3 Different Puppy Search Engine or use DogPile
Back to top
View user's profile Send_private_message 
greengeek

Joined: 20 Jul 2010
Posts: 2669
Location: New Zealand

PostPosted: Wed 07 May 2014, 15:30    Post_subject:  

I'm not technically able to contribute any info about the merits of systemd but from what I read it continues a trend of taking control away from the end user (which can be both good or bad depending on your preferences).

What I mean is - as the kernel has developed and expanded it now contains functions that used to reside outside of it (mouse / video functions etc that used to be standalone). The development of systemd sounds like a continuation of a trend that puts code 'beyond the reach' of people like me - I really enjoy being able to get 'under the hood' and strip / modify code just for the heck of it. I'm not good at it, but I like the feeling of having that control.

Does the development of systemd contribute towards the creation of a "black box" approach - where functionality is modular and the user is locked out from having total control? It seems to me that systemd has the same ugly odour as UEFI - an unnecessary level of isolation that prevents me doing what I want.
Back to top
View user's profile Send_private_message 
technosaurus


Joined: 18 May 2008
Posts: 4380

PostPosted: Wed 07 May 2014, 16:45    Post_subject:  

greengeek wrote:
... the same ugly odour as UEFI - an unnecessary level of isolation that prevents me doing what I want.
fwiw uefi isn't bad. The partition info is all at 1 location with distinct magic for each filesystem and that also allows it to be specified on the bootloader command line (PARTUUID=...). The existing infrastructure had magic values and UUIDs scattered all over the partitions which increased complexity (see guess_fstype) and reduced reliability (a usb drive may be sdb, sdc, ...) the tools just need(ed) updated.

systemd is no different than any other tool like it aside from the fact that it has the benefit of 20/20 hindsight of the past mistakes of others, it could just as easily use busybox ash with builtins like readahead (to preload files), wait $PID (to handle parallel processes) and inotifywatch on a tmpfs (for message transfer) along with judicious use of nofork/noexec applets and shell builtins. As it is, instead of parsing shell scripts, they have to parse config files and then separately load and run many external programs (this load/run takes much longer than even the forking-type busybox applets) ... but then again RedHat doesn't have me bigbass or amigo to audit their scripts, but do have a lot of experienced C programmers that would otherwise be F-ing up GTK+. I say support them on the projects we don't really care about (like systemd) so they spend less time with their fingers in the pie that we eat (gtk)

_________________
Web Programming - Pet Packaging 100 & 101
Back to top
View user's profile Send_private_message 
mavrothal


Joined: 24 Aug 2009
Posts: 1806

PostPosted: Thu 08 May 2014, 00:30    Post_subject:  

bark_bark_bark wrote:
let's not forget why systemd is bad here. systemd is a tool for RHEL developers to establish a monopoly.


I'm not sure that monopolizing is the intention here. Using the words of Lennart Poettering, one of the 2 systemd credited developers (now removed from his wikipedia page!)
Quote:
Linux is still too fragmented, and a developer targeting Linux will have to choose from a variety of APIs, a bazaar of somewhat matching but mostly just chaotic choices that will work on some systems but not on others. I think it would be in our greatest interest to streamline the platform top to bottom, and thus have a clear message what the Linux OS is. And of course, I believe my work in cleaning up the lower levels of our userspace stack is helping to work in that direction
.
The only thing is that in order to achieve that he wants to brake away from the so far APIs and code...
Quote:
Not having to care about portability has two big advantages: we can make maximum use of what the modern Linux kernel offers these days without headaches -- Linux is one of the most powerful kernels in existence, but many of its features have not been used by the previous solutions. And secondly, it greatly simplifies our code and makes it shorter: since we never need to abstract OS interfaces the amount of glue code is minimal, and hence what we gain is a smaller chance to create bugs, a smaller chance of confusing the reader of the code (hence better maintainability) and a smaller footprint.

_________________
Kids all over the world go around with an XO laptop. They deserve one puppy (or many) too Very Happy
Back to top
View user's profile Send_private_message 
bark_bark_bark

Joined: 05 Jun 2012
Posts: 900
Location: USA

PostPosted: Thu 08 May 2014, 16:09    Post_subject:  

mavrothal wrote:
bark_bark_bark wrote:
let's not forget why systemd is bad here. systemd is a tool for RHEL developers to establish a monopoly.


I'm not sure that monopolizing is the intention here.


I disagree, but I would think the only one in their way is Mr Shuttleworth. Mr Shuttleworth is more likely to get total control of linux because he is trying to make people think that Ubuntu and Linux are the exact same thing.

Quote:
Linux is still too fragmented


IMO, linux is not fragmented. It needs more variety. Too many distros are becoming too similar to each other. and it is only getting worse. If linux doesn't get more fragmented, real innovation will halt and we would basically have a "new windows".

_________________
......

Edited_times_total
Back to top
View user's profile Send_private_message 
jamesbond

Joined: 26 Feb 2007
Posts: 2230
Location: The Blue Marble

PostPosted: Fri 16 May 2014, 08:43    Post_subject:  

mavrothal wrote:
Isn't it time for a BSD puppy? Laughing

Did they ever fix the FAT32 bug?

_________________
Fatdog64, Slacko and Puppeee user. Puppy user since 2.13.
Contributed Fatdog64 packages thread
Back to top
View user's profile Send_private_message 
bark_bark_bark

Joined: 05 Jun 2012
Posts: 900
Location: USA

PostPosted: Fri 16 May 2014, 08:58    Post_subject:  

systemd will probably end BSD's existence.
_________________
......
Back to top
View user's profile Send_private_message 
technosaurus


Joined: 18 May 2008
Posts: 4380

PostPosted: Fri 16 May 2014, 09:47    Post_subject:  

bark_bark_bark wrote:
systemd will probably end BSD's existence.
if anything system will reinvigorate the BSDs. I for 1 have plans to puppify a BSD.
_________________
Web Programming - Pet Packaging 100 & 101
Back to top
View user's profile Send_private_message 
Display_posts:   Sort by:   
Page 2 of 10 Posts_count   Goto page: Previous 1, 2, 3, 4, ..., 8, 9, 10 Next
Post_new_topic   Reply_to_topic View_previous_topic :: View_next_topic
 Forum index » Taking the Puppy out for a walk » Announcements
Jump to:  

Rules_post_cannot
Rules_reply_cannot
Rules_edit_cannot
Rules_delete_cannot
Rules_vote_cannot
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001, 2005 phpBB Group
[ Time: 0.1279s ][ Queries: 12 (0.0071s) ][ GZIP on ]