Comments for jcm's blog http://www.jonmasters.org/blog World Organi[sz]ation Of Broken Dreams Thu, 01 Dec 2011 20:35:15 +0000 http://wordpress.org/?v=2.9 hourly 1 Comment on On Citizen Journalism by Pete Zaitcev http://www.jonmasters.org/blog/2011/11/30/on-citizen-journalism/comment-page-1/#comment-135190 Pete Zaitcev Thu, 01 Dec 2011 20:35:15 +0000 http://www.jonmasters.org/blog/?p=1147#comment-135190 It would all make more sense if New York Times haven't turned itself into a lame lapdog of the Democrat machine. It would all make more sense if New York Times haven’t turned itself into a lame lapdog of the Democrat machine.

]]> Comment on Porting Linux: part 1 (of many) by Noah Watkins http://www.jonmasters.org/blog/2011/06/05/porting-linux-part-1-of-many/comment-page-1/#comment-135093 Noah Watkins Sun, 25 Sep 2011 18:30:52 +0000 http://www.jonmasters.org/blog/?p=1122#comment-135093 One thing I would love to see in a book like this is a porting walk through for an existing architecture chosen such that a reader could purchase a cheap development board to do the port for real. Even if the arch already exists in the kernel tree, the book walk through could leave out sections of the port and the reader could either figure out how to implement the missing piece, or consult the existing code in the kernel tree. One thing I would love to see in a book like this is a porting walk through for an existing architecture chosen such that a reader could purchase a cheap development board to do the port for real. Even if the arch already exists in the kernel tree, the book walk through could leave out sections of the port and the reader could either figure out how to implement the missing piece, or consult the existing code in the kernel tree.

]]> Comment on Response to “Why systemd?” by Tomasz http://www.jonmasters.org/blog/2011/04/29/response-to-why-systemd/comment-page-1/#comment-134987 Tomasz Mon, 02 May 2011 21:50:14 +0000 http://www.jonmasters.org/blog/?p=1114#comment-134987 Changing the workflow isn't necessary a bad thing. Sure, it can be an annoyance. But often specific workflow is a result of working around limtations and bad design decisions in tools. Learning new workflow can let you utilize the power of new tool. Only after you acknowledge that some canonical things can be done different and better you appreciate the new design. Changing the workflow isn’t necessary a bad thing. Sure, it can be an annoyance. But often specific workflow is a result of working around limtations and bad design decisions in tools. Learning new workflow can let you utilize the power of new tool. Only after you acknowledge that some canonical things can be done different and better you appreciate the new design.

]]> Comment on Response to “Why systemd?” by foo http://www.jonmasters.org/blog/2011/04/29/response-to-why-systemd/comment-page-1/#comment-134986 foo Sun, 01 May 2011 11:21:40 +0000 http://www.jonmasters.org/blog/?p=1114#comment-134986 sysvinit is unreliable in the case of services depending on each other. You have to manually reorder stuff, or automatically reorder stuff based on dependencies encoded in LSB headers. Automatically reordering stuff is hard, especially on custom setups. With systemd that goes away and the kernel does it automatically. Much nicer than sysvinit. Server boot time matters too. With sysvinit you lose packets when restarting services, not so with systemd. sysvinit is unreliable in the case of services depending on each other. You have to manually reorder stuff, or automatically reorder stuff based on dependencies encoded in LSB headers. Automatically reordering stuff is hard, especially on custom setups. With systemd that goes away and the kernel does it automatically. Much nicer than sysvinit.

Server boot time matters too.

With sysvinit you lose packets when restarting services, not so with systemd.

]]> Comment on Response to “Why systemd?” by oiaohm http://www.jonmasters.org/blog/2011/04/29/response-to-why-systemd/comment-page-1/#comment-134984 oiaohm Sun, 01 May 2011 03:16:09 +0000 http://www.jonmasters.org/blog/?p=1114#comment-134984 Everyone want to forget the init process itself is a block of C code even with system V. It is in charge of shutting the system down. That init command you run to change run levels under system V sends a message to process 1 on the system. dbus is just a different way and more friendly way todo IPC messages. Interfacing by dbus nothing different really. "Modular C coded early boot services included." Did you not read this. Systemd main source codes include the features todo Mount handling down. But big but these are independent modules. So can be replaced or removed. Merging in of inetd kinda came a requirement due to how systemd operates. xinetd/inetd was the first Socket-based Activation system. systemd is the next generation with many improvements so every service can take advantage of xinetd/inetd activation on demand idea even if they are not designed to be xinetd/inetd compatible with systemd. This is why xinetd/inetd cannot mix with systemd. They both will want to be monitoring the same things. mount handling also falls into mount based Activation. Service has started up it goes to use a partition that is not mounted yet. So systemd suspends it until that is mounted. The deeper you dig systemd is an Activation based system. Something completely different in a lot of ways to sys v init system. It is basically impossible todo a full activation based system inside the system v model. Also none of the YAIS (Yet Another Init System) ever has been a fully activation based system. Systemd closest living relation is launchd from OS X. Launchd is only partly in the direction of Activation based system. Activation based system is not an Init system really either. Activation based systems keep on working away after the system has started up. Encrypted hard disk handling (LUKS) is a good example of this in systemd it handles encrypted harddrives on startup also if you plug them in while the system is running. If harddrive requires password drive may wait until have the machine is booted and dbus sends a message asking for password. Also due to it being an activation based system not a init based system. It does house keeping on temp directories and the like. Biggest change is cgroup wrapping of every service so you know what started what. Doing this also would have required a complete rewrite of the shell scripts. Of course I am not going to say for one moment there are not areas in systemd that cannot be refined. Like possibly making units for mount handling and so on run as independent processes so more tolerant to failures. Systemd is the first of its kind of system on Linux other than xinetd and inetd. This is important to remember every other init system that has ever been on linux is a rework of the sys v design one way or another. So perfectly fair to call the others YAIS. If systemd is yet another something. Its Yet Another Inetd. Just inetd on serious booster drugs so it can boot the complete system just compatible services. Yes systemd behavior is more like a inetd than a system v init. A revamp of this size is a chance to fix a lot of historic mistakes and make a few new ones. Everyone want to forget the init process itself is a block of C code even with system V. It is in charge of shutting the system down. That init command you run to change run levels under system V sends a message to process 1 on the system. dbus is just a different way and more friendly way todo IPC messages. Interfacing by dbus nothing different really.

“Modular C coded early boot services included.” Did you not read this.
Systemd main source codes include the features todo Mount handling down. But big but these are independent modules. So can be replaced or removed.

Merging in of inetd kinda came a requirement due to how systemd operates.

xinetd/inetd was the first Socket-based Activation system. systemd is the next generation with many improvements so every service can take advantage of xinetd/inetd activation on demand idea even if they are not designed to be xinetd/inetd compatible with systemd. This is why xinetd/inetd cannot mix with systemd. They both will want to be monitoring the same things.

mount handling also falls into mount based Activation. Service has started up it goes to use a partition that is not mounted yet. So systemd suspends it until that is mounted.

The deeper you dig systemd is an Activation based system. Something completely different in a lot of ways to sys v init system. It is basically impossible todo a full activation based system inside the system v model. Also none of the YAIS (Yet Another Init System) ever has been a fully activation based system. Systemd closest living relation is launchd from OS X. Launchd is only partly in the direction of Activation based system.

Activation based system is not an Init system really either. Activation based systems keep on working away after the system has started up.

Encrypted hard disk handling (LUKS) is a good example of this in systemd it handles encrypted harddrives on startup also if you plug them in while the system is running. If harddrive requires password drive may wait until have the machine is booted and dbus sends a message asking for password.

Also due to it being an activation based system not a init based system. It does house keeping on temp directories and the like.

Biggest change is cgroup wrapping of every service so you know what started what. Doing this also would have required a complete rewrite of the shell scripts.

Of course I am not going to say for one moment there are not areas in systemd that cannot be refined. Like possibly making units for mount handling and so on run as independent processes so more tolerant to failures.

Systemd is the first of its kind of system on Linux other than xinetd and inetd. This is important to remember every other init system that has ever been on linux is a rework of the sys v design one way or another. So perfectly fair to call the others YAIS. If systemd is yet another something. Its Yet Another Inetd. Just inetd on serious booster drugs so it can boot the complete system just compatible services. Yes systemd behavior is more like a inetd than a system v init.

A revamp of this size is a chance to fix a lot of historic mistakes and make a few new ones.

]]>