Users/Developers Threatening Fork Of Debian GNU/Linux

[gens]

you, like average dumbass systemd hater, got it wrong
systemd resolves dependencies and starts the leaves in parallel.
upstart has backwards depenencies i.e. when some event happens it does something.
i.e. if you have some device, it starts daemon responsible for it. even if you don't have client and don't need it(yet)
systemd does on demand startup. when it needs to start something it builds dependency graph and starts all leaves in parallel.
for example when client connects to server socket it starts server.
and it has much more leaves available on each step because it does not have false dependencies like "this server needs that server". because server really needs only socket and socket is opened by systemd and so it starts all servers in parallel.

from here
"The systemd position statement claims that the Upstart dependency tree is "upside down" by starting services when their dependencies are ready, instead of starting the service's dependencies when the service should be started. This ignores the reality that a Linux system is fundamentally event-driven. It is meaningless to suggest that all the dependencies should be auto-started, when some of these dependencies will be tied to hardware events that the init system does not control. This merely repeats the existing flaws with sysvinit. "

it's not nice to insult people
no icecream for you today

[pal666]

as i said, that blog is extremely imprecise and some times just plain wrong
for example the (now missing) picture that shows how socket activation "works" did not explain in any way how socket activation works and was wrong (incomplete=wrong)
best case socket activation would mean a process runs its startup (__libc_start, reading configs and such) then waits for the process it depends on to start completely
it is practically the same as normal start up because it reading that config/locale/whatever files would make the other process it depends on to fully start start slower
edit: it would also mean nonlinear disk access

stop giving me links
especially ones to propaganda material

man you just dumb as shit
it is not incomplete documentation, it is you have too small brain to understand it.
socket activation works because it is possible to start both client and server in parallel. it is possible to start many clients and servers in parallel. even with circular deps.
yes it would mean nonlinear access
systemd supports readahead and you can use ssd

[jrch2k8]

well to be honest linear and non linear access is a illusion most of the time because the kernel take the decision to go either way depending the efficiency of the media through the layers and the same happens with RAM, you can request continuous chunks but the kernel make the final decision behind curtains even tho it looks linear due to the virtualisation of pages and address spaces. ofc unless you internally in the kernel play hell with kmalloc and DMA but can be very insecure without proper handling

[bearded_linux_admin]

man you just dumb as shit
it is not incomplete documentation, it is you have too small brain to understand it.

With each post you make, the mental age I assign to you gets lower and lower. Do your parents know you are using their computer? Do you not realise that the only one that comes across "dumb as shit" as you say is you? Very few people will actually listen to what you have to say when you communicate in this way.

For all I know the things you have to say might actually be worth considering, but the signal in your message gets lost in the noise of your swearing.

Grow up, son.

[pal666]

from here
"The systemd position statement claims that the Upstart dependency tree is "upside down" by starting services when their dependencies are ready, instead of starting the service's dependencies when the service should be started. This ignores the reality that a Linux system is fundamentally event-driven. It is meaningless to suggest that all the dependencies should be auto-started, when some of these dependencies will be tied to hardware events that the init system does not control. This merely repeats the existing flaws with sysvinit. "

it's not nice to insult people
no icecream for you today

lol moron you reiterated my words to me and didn't understand it
systemd has dependency tree
upstart has event tree, which is backwards

for example. you have two units A and B, both requiring third unit C.

in upstart you write rules "start A and B when C started"
and you will get A and B whenever C is up regardless of whether you need A or B or none

in systemd you write rules "when A needed, start C prior of it" and "when B needed, start C prior of it"(btw, most of the time you don't even need to write these rules - systemd will start dependencies automatically with socket, dbus, etc activation)
so when something (maybe user, maybe other unit) needs A, systemd starts C(if not started yet), A. when something needs B, systemd starts C(if not started yet), B. in other words, if you need A, you will have C and A started. if you need B, you will have B and C started. if you need both A and B, you will have all 3 started. if you need neither A nor B, you will not have them started. but you will have C started if it is needed by something other.

i.e. systemd builds dynamic system with only needed units started, while upstart builds static system with everything started

[pal666]

With each post you make, the mental age I assign to you gets lower and lower. Do your parents know you are using their computer? Do you not realise that the only one that comes across "dumb as shit" as you say is you? Very few people will actually listen to what you have to say when you communicate in this way.

For all I know the things you have to say might actually be worth considering, but the signal in your message gets lost in the noise of your swearing.

Grow up, son.

do you realise, that you messages are not very polite ? so you shouldn't teach other people politeness, and speak to the mirror instead. i answer politely when ppl ask politely. when ppl say "you are all horribly wrong" when in reality they should say "i can't understand this, please enlighten me", then i answer impolitely.

[gens]

well to be honest linear and non linear access is a illusion most of the time because the kernel take the decision to go either way depending the efficiency of the media through the layers and the same happens with RAM, you can request continuous chunks but the kernel make the final decision behind curtains even tho it looks linear due to the virtualisation of pages and address spaces. ofc unless you internally in the kernel play hell with kmalloc and DMA but can be very insecure without proper handling

i was talking about disk access
non linear access to traditional (non-SSD) disks requires the "needle" to jump around
making disks that are much slower then the cpu even slower

RAM does not have that problem
you can have a page of memory anywhere in ram mapped to anywhere in virtual memory and it won't matter (page table lookup overhead is still there non the less)
that a section of memory is sequential in physical RAM only matters when copying that part of memory to or from a device that requires a buffer bigger then 1 page
and that is handled by either the IOMMU or by reserving a part of RAM address space in advance (linux kernel can do bout, afaik)

bigger problem with data being scattered in many pages is that it causes a lot of cache trashing
that does not matter much in this case
it is also the reason why modern game engine makers (like DICE, OGRE (for 2.0)) are rewriting performance sensitive parts of their engines in a data-driven matter
(in contrast to OO, that is popular these days)

[bearded_linux_admin]

It is not up to the anti-systemd crowd to tell developers what they must and must not spend their own free time on.

I was under the distinct impression that the systemd project and most of its' principal developers worked for Redhat? So not so much their own time, as it is pushing a direction that is profitable in some way for RedHat.

[gens]

i was talking about disk access
non linear access to traditional (non-SSD) disks requires the "needle" to jump around
making disks that are much slower then the cpu even slower

to expand to cover what jrch2k8 said
yes, the kernel keeps files in memory to minimize reads/writes to the hardware itself
and there is the disks internal cache and probably a couple smaller ones on the bus and such
but when the computer starts they are all empty and have to be read from the disk

i found a nice and detailed explanation on all that here

[jrch2k8]

i was talking about disk access
non linear access to traditional (non-SSD) disks requires the "needle" to jump around
making disks that are much slower then the cpu even slower

RAM does not have that problem
you can have a page of memory anywhere in ram mapped to anywhere in virtual memory and it won't matter (page table lookup overhead is still there non the less)
that a section of memory is sequential in physical RAM only matters when copying that part of memory to or from a device that requires a buffer bigger then 1 page
and that is handled by either the IOMMU or by reserving a part of RAM address space in advance (linux kernel can do bout, afaik)

bigger problem with data being scattered in many pages is that it causes a lot of cache trashing
that does not matter much in this case
it is also the reason why modern game engine makers (like DICE, OGRE (for 2.0)) are rewriting performance sensitive parts of their engines in a data-driven matter
(in contrast to OO, that is popular these days)

was talking about disk access too, but anyway my point was linear requests are not always performed linear and the kernel/hardware hide it because ssd,non-ssd, Raid, etc. hardware has become non deterministic due to controller optimisations, specific filesystems implementations, hardware gotten very complex through the years(more dense plates, parallel "needles", varying rotation speed, micro controllers, caches, etc.), so the performance between linear and nonlinear is non deterministic too depending the combination of factors, so one should always test properly and have a plan B depending the feedback.

about memory yeap your are right even tho the kernel have many tricks to make scattered access cache friendly(ish) specially when handling big data but yeah i agree