Replacement of Init System

serverhamster said:
Ubuntu tries to use Upstart. It was introduced some years ago, and still leads to several unstable situations.
Mounting NFS shares is unreliable. Sometimes they are mounted, sometimes they are not.
RAID devices are sometimes not assembled on time.
The boot log (when finally reintroduced) is full of errors like Failed to resolve server... because of parallelization.
libvirtd tries to start virtual machines on boot before the network is up when those machines need network storage. Things like that.
On top of that, by default, the user sees an animation on boot, but no information. This isn't evolution. Sounds bad? It is! Fast booting is nice, but if it can't be done reliably, I don't want it. Let's look closely at Ubuntu and Fedora and learn from their mistakes.

On a positive note, all those issues drove me to seek a reliable system. So I ended up here.

Read that link, and I was reminded of another reason why the status quo seems fine for now. If I want to explain in one paragraph (say, in an email) how to do something ( establish a crontab
entry...) it is helpful if an overview is included (Say, a complete newbie receiving the email).
Thus, crontab doable... sendmail a bit more difficult (I'd have to
be semi-expert...) but, yet another aspect? (an XML file to edit and process...) should
prove to add no more than a sentence or two to the entire explanation. Potentially less easy...
Also, I appreciate one-by-one (rc.d)... loadings at the boot so messages hinting and not-done
configurations, etc appear. A front-end which may hide those would move the tweaks which may
be due from "soon" to "never"... ( If this or any other reasoning I've posted in this thread should be unfounded due to
misinformation or mistaken first impressions, I apologize and will be eventually shown to
be in error.)
 
If something being old or the fact that it works was really a good reason not to change then we could all just have stuck with paper and not bothered having computers in the first place.

There is a saying which goes like this: There are two kinds of fools. One who say that this is old and therefore good, and those who say that this is new and therefore better.

If it takes me 5 minutes to migrate a system to a startup system which saves me 5 seconds on bootup, then I need to restart this thing 60 times to break even. And that does not include bugs introduced. I also think that the time is better spent in getting hibernate working.
 
Suspend or hibernate are a distraction, it's not the same people working on both and therefore not an either/or choice. Volunteers cannot be assigned to work on projects.

If there were a noticeably better startup system and an easy way to migrate, a lot of people would switch. As an example, look at pkgng.

However, when you start talking about features that touch on bigger compatibility issues, like XML or converting config files from plain text into another format, it becomes much, much harder to sell.
 
Crivens said:
If it takes me 5 minutes to migrate a system to a startup system which saves me 5 seconds on bootup, then I need to restart this thing 60 times to break even.

Conversely, if it takes one team of 5 developers 1 week to get ALL instances of the operating system to save 5-10 seconds on every single boot up for the next 10+ years, the economics add up pretty quick for it being a net benefit to the community (numbers pulled at random, but you get the point).

I think the configuration file problem is a somewhat parallel issue, that launchd solves for startup and daemon management only. Ideally, if you were to go to XML you'd want all config files to be XML - eventually. Make no mistake, that will not happen any time soon, but that doesn't mean no one should at least attempt to try and use standard configuration files in future projects...

No, I don't particularly like XML myself either, but at least it is standardized (which is more than we can say of the mish-mash of configuration file formats on a typical box) - and that will be beneficial to future users.

If i need to configure a new Unix box (this isn't just a FreeBSD issue) to say, run a few DNS zones, SMTP mail relay, and a few periodic jobs from cron, I need to deal with 5 different configuration file formats there for a start - each with their own syntax to learn. And that's just a fairly simple, limited-function machine. Anyone trying to make it "friendly" via a GUI or web configuration app needs to write and debug 5 different parsers...

Sure, I've spent 15 years doing this stuff and I know how to do it, but for someone starting out, it's a bit of a pain.

And really, there's not any real need for it - none of the programs are storing any magic in their configuration file that couldn't be stored in a standardised way.
 
  • Thanks
Reactions: Kt
Crivens said:
There is a saying which goes like this: There are two kinds of fools. One who say that this is old and therefore good, and those who say that this is new and therefore better.

If it takes me 5 minutes to migrate a system to a startup system which saves me 5 seconds on bootup, then I need to restart this thing 60 times to break even. And that does not include bugs introduced. I also think that the time is better spent in getting hibernate working.

You'll never know if something is better or not unless your actually willing to try something out rather than projecting your fears on an imaginary situation.

If I understood the original OP properly, he'd tried it with OpenRC, had favourable results, was reporting that fact, and was then dumped on by the status quo vested interests for daring to suggest change be considered.

He then tried to defend his suggestion and got dumped on a bit more.

Frankly, I couldn't care less whether his suggestion made it in to base or not but as he, generously has done some work and was prepared to share then I believe he deserves better than he got.

Personally, I'll look at anything that might improve the rather appalling boot times I'm finding on the latest FreeBSD and PCBSD releases since I'm interested using BSD in a commercial product that could benefit from being as near to instant on as possible.

I'm quite happy to have my own custom version of BSD thats better than base and has encryption in ZFS and not share at all. I was just sticking up for the OP.
 
Kt said:
You'll never know if something is better or not unless your actually willing to try something out rather than projecting your fears on an imaginary situation.
That is exactly the point. You need to check the suggestions and provide hard data.
The "this is new and therefore better" argument is no argument at all, and it got several projects (Linux user land, I'm looking at you) in the sorry state where some parts are these days. The opposite is also true, it keeps us back for no reason other than "was good enough for my grandfather, thus good enough for me".
Kt said:
If I understood the original OP properly, he'd tried it with OpenRC, had favourable results, was reporting that fact, and was then dumped on by the status quo vested interests for daring to suggest change be considered.
If I remember correctly, he was testing this also in a complete different user land, thus making the results a bit un-portable.
Kt said:
He then tried to defend his suggestion and got dumped on a bit more.

Frankly, I couldn't care less whether his suggestion made it in to base or not but as he, generously has done some work and was prepared to share then I believe he deserves better than he got.
Yes, he deserves credit. But I would not call it being 'dumped on' what happend to him. He was told that he was not running a reference system, then he tried to defend the view that running a gnu user land does not make it a clean install. That is where his credibility tanked a bit, IMHO. After that, it diverged a into comparison of different startup systems. And when someone threw systemd into it, the thread was doomed.
Kt said:
Personally, I'll look at anything that might improve the rather appalling boot times I'm finding on the latest FreeBSD and PCBSD releases since I'm interested using BSD in a commercial product that could benefit from being as near to instant on as possible.
Since most time is spent during the HW probe, and not after init has been started (at least on my machines), you may have best luck to get the different drivers to work in parallel during startup of the kernel. Usually I have about 3-4 seconds between init and xmd. Not using the login managers of kde/gnome can save a lot of time. But for servers, a boot usually ends in a tty login.
So this depends on the thing you want to do.
 
  • Thanks
Reactions: Kt
Crivens said:
That is exactly the point. You need to check the suggestions and provide hard data.
The "this is new and therefore better" argument is no argument at all, and it got several projects (Linux user land, I'm looking at you) in the sorry state where some parts are these days. The opposite is also true, it keeps us back for no reason other than "was good enough for my grandfather, thus good enough for me".

If I remember correctly, he was testing this also in a complete different user land, thus making the results a bit un-portable.

Yes, he deserves credit. But I would not call it being 'dumped on' what happend to him. He was told that he was not running a reference system, then he tried to defend the view that running a gnu user land does not make it a clean install. That is where his credibility tanked a bit, IMHO. After that, it diverged a into comparison of different startup systems. And when someone threw systemd into it, the thread was doomed.

Since most time is spent during the HW probe, and not after init has been started (at least on my machines), you may have best luck to get the different drivers to work in parallel during startup of the kernel. Usually I have about 3-4 seconds between init and xmd. Not using the login managers of kde/gnome can save a lot of time. But for servers, a boot usually ends in a tty login.
So this depends on the thing you want to do.

I would call it dumped on. To my mind the initial responses the OP received came across as rude and yob-ish.

I don't believe I said the OP's thing would be better but I was prepared to consider the possibility that it might have been while also being prepared to be wrong.

I do think that the whole of the boot sequence needs to be made as fast as possible and naturally as that is a core part of the system then it will involve risk.

On some recent default installs of both FreeBSD and PCBSD both on different types of bare metal and in VM's the boot sequences were taking more than a minute due to significant pauses in the BTX loader and then the init sequence going slow. Scanning the forums here and the PCBSD ones seems to indicate that others are finding similar delays.

So far the objections raised to even considering changes in the init area seem to relate to:
  1. Projected risk of instability
  2. Perceived learning curve due to that change
  3. "it's ok as it is because it's working"
  4. we don't need faster because we run servers

I recently read some responses on the [post=34581]Why is BSD failing[/post] thread that said a long time BSD server user who'd gone to Linux was afraid of a bit of hard work. I find that sad and ironic (broad brush strokes).

According to here: http://www.freebsd.org/about.html FreeBSD prides itself on performance.

Currently, the boot sequence doesn't seem to meet that criteria.

On the same hardware and vm setups I did a comparison with Chrome OS and some research OS's and they booted within < 5 seconds to a GUI in the VM and even faster on bare metal.

As I said before, I don't really care if FreeBSD et all was to accept changes that made it faster but I'll look at any efforts by others and re-use, re-apply etc as necessary to make my own installs faster.
 
Kt said:
I don't believe I said the OP's thing would be better but I was prepared to consider the possibility that it might have been while also being prepared to be wrong.
As should anyone. Closing the mind to solutions beforehand should be left in the realm of politicans IMHO.
Kt said:
I do think that the whole of the boot sequence needs to be made as fast as possible and naturally as that is a core part of the system then it will involve risk.
The question is if you consider the tradeof as sufficient. If you need reliability and reboot once a year, then this question is easily answered. You do not take that risk. If your typical use involves a lot of rebooting, then the answer might be something else.

As stated before, my systems spend only some seconds between calling init and offering the login screen, so for my typical usage pattern I have spend more time in this thread than I could save by speeding up the boot sequence. So this is about academica for me.

Kt said:
On some recent default installs of both FreeBSD and PCBSD both on different types of bare metal and in VM's the boot sequences were taking more than a minute due to significant pauses in the BTX loader and then the init sequence going slow. Scanning the forums here and the PCBSD ones seems to indicate that others are finding similar delays.
The boot can be divided into three parts:
  • BIOS
  • Kernel
  • init

How much time is spent in the BIOS can not be changed by the kernel. The time spent in BIOS or Kernel can not be changed by the init system. Speeding up system init can introduce risks for little benefit, speeding up kernel bootup can (at least on my typical use cases) save a lot more time. That is why I use custom kernels, without the SCSI delay and without the drivers I do not need to boot the machine. This may save only little in space in the kernel file, but not probing for the hardware which is not there speeds up the boot process damatically. Maybe this is what you experience.
Kt said:
So far the objections raised to even considering changes in the init area seem to relate to:
  1. Projected risk of instability
  2. Perceived learning curve due to that change
  3. "it's ok as it is because it's working"
  4. we don't need faster because we run servers

Point 1: should be taken into account.
Point 2: should also matter, but I do not see how that point was made.
Point 3: who made that point?
Point 4: this point is not accurate I think. Servers typically are rebooted once in a blue moon, thus the savings from speeding up booting are not as vital as taking the risk of bricking the system. Speeding up startup is simply less important.
Kt said:
I recently read some responses on the [post=34581]Why is BSD failing[/post] thread that said a long time BSD server user who'd gone to Linux was afraid of a bit of hard work. I find that sad and ironic (broad brush strokes).
Ahm, I suspect a C&P error here because I do not see how clamav plays into this...
 
Parallel execution of start up shell scripts is always a potential minefield because of dependencies to for example proper time and network connectivity.

Here's a nice thread about net/sixxs-aiccu on OpenWRT and why it's no longer integrated in OpenWRT.


http://www.sixxs.net/forum/?msg=general-7418538
Basically the developers of OpenWRT made changes to aiccu service that made it to try to connect to the central server even if it failed repeatedly because of wrong time, many devices where OpenWRT is used lack a proper hardware clock and require setting the time trough ntp. This resulted in the central server being hammered with many connections and the client being banned for excessive number of connections.

The SixXS developers refused to "fix" their service not to ban clients that kept hammering the central server because in their opinion OpenWRT should guarantee that the ntp service sets proper time before starting aiccu and the aiccu service could either fail immediately in case of wrong time or succeed and continue as normal.

I'm completely on SixXS's side on this argument if it's not clear.
 
Crivens said:
The question is if you consider the tradeof as sufficient. If you need reliability and reboot once a year, then this question is easily answered. You do not take that risk. If your typical use involves a lot of rebooting, then the answer might be something else.

As stated before, my systems spend only some seconds between calling init and offering the login screen, so for my typical usage pattern I have spend more time in this thread than I could save by speeding up the boot sequence. So this is about academica for me.

The boot can be divided into three parts:
  • BIOS
  • Kernel
  • init

How much time is spent in the BIOS can not be changed by the kernel. The time spent in BIOS or Kernel can not be changed by the init system. Speeding up system init can introduce risks for little benefit, speeding up kernel bootup can (at least on my typical use cases) save a lot more time. That is why I use custom kernels, without the SCSI delay and without the drivers I do not need to boot the machine. This may save only little in space in the kernel file, but not probing for the hardware which is not there speeds up the boot process damatically. Maybe this is what you experience.

Thanks for explaining a boot sequence, not really necessary as I already know this, but perhaps useful to other readers. Just because your experience is fine, doesn't mean others are.

Point 1: should be taken into account.

Agreed it should be a factor, but not a reason for not investigating something and trying different options. Using it as a reason for not doing the investigation or trying different ways of improving it is rather poor.

Any change, of any kind, involves risk. If any users are so concerned by that risk then they probably should never upgrade since there will always be a chance that their specific setup will tank.

In any event, anyone truly concerned by stability would never be seen dead running the latest and greatest version of any operating system. The prudent thing to do is to lag behind a couple of releases and wait until its been throughly tested by the wider community.

Point 2: should also matter, but I do not see how that point was made.

I suggest you read back through the thread I don't really want to make this personal.

So your saying that if there is a learning curve (i.e. make some sort of effort) then it should be a reason not to have a change. Well, that could pretty much rule out most changes.

Then again, people concerned about having to learn could always decide not to upgrade and stay with their safe and stable versions that require no extra learning on their part.

Point 3: who made that point?

Sorry, I'm not going to make this personal and name names. Read back through the thread.

Point 4: this point is not accurate I think. Servers typically are rebooted once in a blue moon, thus the savings from speeding up booting are not as vital as taking the risk of bricking the system. Speeding up startup is simply less important.

For you specifically yes, but not for other server uses - spinning up VM's (ala AWS) would be one I can think of right now. Also, FreeBSD is not just for server uses is it.

In any event since you don't need to reboot that often then you shouldn't mind if its faster and of course since stability is so important to you then your safest bet would be be several OS's releases behind anyway.

Ahm, I suspect a C&P error here because I do not see how clamav plays into this...

[thread=34581]Try this one, I'd use the wrong bb code[/thread]

I must say that I find the reactions on here quite amazing sometimes - on the one hand there seems to be a huge amount of quite rightly deserved pride in the BSD Community's ability to implement well thought out skillfully designed solutions while on the other hand from some quarters at least an absolute inability to put individual needs aside and as a result outright rejection of investigating how to achieve said skill fully designed solutions to a problem.

According to this: http://www.freebsd.org/advocacy/myths.html

BSD makes a great server. It also makes a great desktop.

Slow startups on default installs of both PCBSD and FreeBSD would seem to make that statement no longer as valid as it could be if we look at the startup times of others.
 
Kt said:
Agreed it should be a factor, but not a reason for not investigating something and trying different options. Using it as a reason for not doing the investigation or trying different ways of improving it is rather poor.
Any change, of any kind, involves risk. If any users are so concerned by that risk then they probably should never upgrade since there will always be a chance that their specific setup will tank.
So your saying that if there is a learning curve (i.e. make some sort of effort) then it should be a reason not to have a change.
I must say that I find the reactions on here quite amazing sometimes - on the one hand there seems to be a huge amount of quite rightly deserved pride in the BSD Community's ability to implement well thought out skillfully designed solutions
My apologies, but...
Here, I see this "different option" "improving it" "some sort of effort" "skillfully
designed solutions" as an unproven assumption, or set of assumptions, that the init process undergoing a fundamental change is already proven to be advantageous to the majority of
present and future users of the operating system. Nothing in these threads or the links from
them have shown that to be the case so far, at least from this viewpoint, and several others, so far in
this thread... *even if* it is indeed advantageous.
 
jb_fvwm2 said:
My apologies, but...
Here, I see this "different option" "improving it" "some sort of effort" "skillfully
designed solutions" as an unproven assumption, or set of assumptions, that the init process undergoing a fundamental change is already proven to be advantageous to the majority of
present and future users of the operating system. Nothing in these threads or the links from
them have shown that to be the case so far, at least from this viewpoint, and several others, so far in
this thread... *even if* it is indeed advantageous.

You won't know unless you try.

Anything else is just "Change is bad and scary" talk based on the points previously mentioned in earlier posts and lots of assumptions as to what a real implementation might entail.

By all means, if you wish to live in fear, and never evolve your personal situation then that is your personal choice.

I love it when people claim to speak for the many or the majority. I think I'd rather hear from 'the many' individually thanks.

Again as with anyone who doesn't want to evolve their system out of fear, the extreme solution is don't upgrade .. ever.

The rather more rational, level headed, responsible approach is to delay your upgrades, and allow things to settle in.

I rather bet that the dissenters do upgrade their systems from time to time. *gasp*
I also bet that those upgrades sometimes effect core parts of the OS.

As for advantageous, If you don't think speed is an advantage then don't upgrade. Don't accept any kernel performance enhancements either.

I suspect, although I wouldn't dream of speaking for the many, that speed is considered advantageous.
 
And the canonical method of proving an assumption wrong is by a presentation why it is so, vs simply arguments why it is so.

Such a presentation in this case, I surmise would take a lot of development time and effort. If that is the reason for many of the posts in this thread, maybe the case should be put directly to those who would be involved. (Or I am misunderstanding and this thread is for that purpose, just not explicity stated as such).
 
jb_fvwm2 said:
And the canonical method of proving an assumption wrong is by a presentation why it is so, vs simply arguments why it is so.

Such a presentation in this case, I surmise would take a lot of development time and effort. If that is the reason for many of the posts in this thread, maybe the case should be put directly to those who would be involved. (Or I am misunderstanding and this thread is for that purpose, just not explicity stated as such).

What assumptions ? Why is this to be about proving assumptions wrong ? What do you need to prove ?

This thread is about "Replacement of the Init System"

If a Replacement was proposed for the init system then it should be "discussed", "goals set", "designed", "implemented" and "tested" before it could be "accepted" or "rejected" by an individual user of BSD.

Instead what's happened is quite different.

I'll paraphrase "No, init is sacred, we mustn't touch init because (insert whatever sweeping objection I can think of/personal reason for not having to deal with a change)"

Nothing should be sacred in an OS.
 
(damn i really wish I could edit my posts - sorry - that last one isn't quite right but it will have to do.)
 
I'm not saying that the current init system is perfect, but here's an anecdote:

A buddy and I walk into a computer lab. I dig my netbook out of its case, set it down, go find a free socket and plug it in, insert the boot stick (it's a laptop, so full encryption), boot (requiring a password (encryption, remember?)), login (also requiring a password), start X, open a terminal and get to work. In the meantime, my buddy is still waiting for a login prompt on the lab's Windows PC that was already running...

Can FreeBSD's init system be improved? Sure, some people like parallelisation and admittedly the output could be a bit tidier/niftier. Should the work on that be a top priority? Based on the above: nah, whenever someone gets around to it that's quite good enough.

Fonz
 
  • Thanks
Reactions: Kt
I've never understood the fixation people have on 'boot must be faster'. How often are people booting? Are there really people rebooting their systems 30 times a day? Does is really matter if a system takes 15 seconds to boot vs 1 minute?

Parallel running of init scripts is great ... until you need to debug why a certain service isn't starting.

Everyone who is advocating for change needs to stop, think, and fully instrument the current system. Where, exactly, are the slow parts of the boot process? Does it really matter that bit takes 30 seconds to run through all the rc.d scripts, when it takes 30 seconds to POST, 10 seconds in the loader, and 45 seconds to probe all the hardware?

Until someone site down and times out every single part of the POST, BIOS, loader, kernel, hardware probe, init, login process, this entire conversation is moot.
 
phoenix said:
I've never understood the fixation people have on 'boot must be faster'. How often are people booting? Are there really people rebooting their systems 30 times a day? Does is really matter if a system takes 15 seconds to boot vs 1 minute?

Here here. I fully agree.

I also don't understand why people try to bring so much irrelevant arguments to the table:

Kt said:
By all means, if *you* wish to live in fear, and never evolve your personal situation then that is your personal choice.

It's also none of your concern. This isn't a therapy session and apart from the fact that your remark is rudely judgemental, it's also highly irrelevant.

The fundamental question of this thread (which I think still hasn't been answered by anyone in favour of making arbitrary Linuxey changes to the current init system), is, "Why should the init system be changed to something different?"

I see this as nothing more than a rhethorical question. But if I were to answer it I'd say; given all the recent hackery dackery in working Linux distributions that are only interesting for a few aggressive and almost parasitic "tinkerers", FreeBSD should stay as far away from this as it possibly can.
 
donduq said:
Here here. I fully agree.

I also don't understand why people try to bring so much irrelevant arguments to the table:

It's also none of your concern. This isn't a therapy session and apart from the fact that your remark is rudely judgemental, it's also highly irrelevant.
.

Why shouldn't it be my concern ? I'm a BSD user too. I like BSD. No thing is perfect though and as such it can evolve

I also believe that allowing "fear-based reasoning" or "laziness-based reasoning" to be used as an excuse for not even attempting or looking at something to be wrong.

As it happens, I believe there is some effort underway to look in to this so its all moot.

Have a good day.

Namaste. :)
 
Kt said:
Why shouldn't it be my concern ? I'm a BSD user too. I like BSD. No thing is perfect though and as such it can evolve

I also believe that allowing "fear-based reasoning" or "laziness-based reasoning" to be used as an excuse for not even attempting or looking at something to be wrong.

As it happens, I believe there is some effort underway to look in to this so its all moot.

Have a good day.

Namaste. :)

I don't know. It becomes obvious when someone hasn't taken the effort or responsibility of acknowledgement of what works and why. I don't need to be an engineer or computer scientist to understand how *BSD is stable. Also taking a step back and realizing that though FreeBSD isn't owned by any one specific entity it's governed by it's committers and core.

Also if you look at how some of the linux distros run into the same administrative issues by attempting to fix layers upon layers of what's already broken to some extent is do to corporations who don't actually care about anything but lock-in policies while poisoning the current ecosystem. Case in point.... Look at redhat's business model to tie centos users back into their M$ linux. Then again Lennart Poettering thinks posix and BSD are irreverent.

More of the same:

http://www.itwire.com/business-it-n...m-vendors-can-harm-small-projects-openbsd-dev

https://queue.acm.org/detail.cfm?id=2349257
 
UNIXgod said:
I don't know.

Clearly. I refer the right honourable gentleman to the previous posts.

Also if you look at how some of the linux distros run into the same administrative issues....[/quote
More of the same:

Your political views and the failings of others should have no relationship to the topic at hand.
 
phoenix said:
Everyone who is advocating for change needs to stop, think, and fully instrument the current system. Where, exactly, are the slow parts of the boot process? Does it really matter that bit takes 30 seconds to run through all the rc.d scripts, when it takes 30 seconds to POST, 10 seconds in the loader, and 45 seconds to probe all the hardware?

Until someone site down and times out every single part of the POST, BIOS, loader, kernel, hardware probe, init, login process, this entire conversation is moot.

That is the point I tried to make. But since this is now more about how a different init system can speed up reaching the point where init is actually started...

Kt said:
Why shouldn't it be my concern ? I'm a BSD user too. I like BSD. No thing is perfect though and as such it can evolve.
That most likely was a reminder that people do not like other people to p*ss into their porridge, even when they currently have toast for breakfast. Making rude remarks and personal attacks does not help your cause either, and I may need to point out that I, too, found these remarks rude and childish.

Kt said:
Your political views and the failings of others should have no relationship to the topic at hand.
To cut this short: Do you claim that no one but you has any idea of what's best here? Yes or No?

And, BTW, I heard that good old DOS is booting so fast on modern HW that it reaches the GUI some seconds BEFORE power on.
 
Crivens said:
To cut this short: Do you claim that no one but you has any idea of what's best here? Yes or No?

God No.

I never claim to know whats best, but I do rather like the idea of what's best being discovered without personal bias in an open forum.

I also:
  • Don't intentionally claim to speak for anyone other than myself.
  • Don't use such claims to bolster my arguments
  • Don't reject out of hand ideas or the suggestion that some change be considered/investigated because of my own individual needs or fears or unwillingness to learn
  • Don't allow my political/activist views (which I do hold) to affect my judgement on software related matters

What I do do is:
  • Try to Listen & Learn all the time
  • Feel free to make mistakes as often as is necessary in order to learn from and admit those mistakes to myself and others
  • Stand up to people who to my mind use bullyboy tactics to shut me down
  • Defend those being attacked (according the to merits of the case)
  • Try to appreciate the value in all even though that can be hard sometimes
  • Look at suggestions with as open a mind as possible, and in this particular context, try to look at it from a community-wide perspective.

If anything I have written in my posts thus far have sounded rude then I can only apologise for any offence that has really been felt by those who felt that offence but since I know that has not been my intention and I also know to well that I have absolutely no control how others freely choose to perceive me I won't beat myself up about it. My days of feeling a need to 'fit in' or 'modify my behavior' in order to please others are long gone.

I am the first to admit that one of my biggest failings is my passion for IT (it's a huge time sink) which combined with a difficulty of suffering fools gladly (that's just a turn of phrase not meant as an attack on anyone other than myself) sometimes leads me to make quite impassioned and very honest statements.

If I have a pet forum related peeve, it's those people on the forums that run in to an ongoing discussion, clearly haven't taken the time to read and understand the flow of an interesting debate, often say that they haven't even, and then spout something seemingly quite random in an attempt to try and score some sort of point. To my mind that sort of activity is rather rude and shows a singular lacking on their part but thats ok they are free to show themselves in that way. I imagine I'm not the only one that sees those sorts of postings for what they truly are.

As a person, I am very direct and honest with myself and sometimes perhaps a too honest with others but then I prefer that people are like that like to me really. It's often not the case and leads to all sorts of misunderstandings. :\

I'm afraid I'm not the sort of person to ask "Does my backside look big in this outfit?" when the person asking is really looking for some sort of ego boost but then that's because I value how people behave rather than how they look and so show my support by being honest instead. :e

All too often, in the open source communities, I am faced with people that fail (actively or passively) to see beyond their own individual needs and I feel that in the process opportunities for the community as a whole are stifled and lost. Something I've never gotten on with is the sometimes outright hate-based zealotry that occurs but that's another story which I won't bore you with.

Anyway, enough, I'm tired of this exchange. It's been interesting and educational in a variety of ways thus far so "Thank you for that" :) but I won't be commenting further on this particular topic.

I'll hand the microphone to the next poster, this soap box is about to be vacated :)

Good luck and Namaste. :)
 
To clarify my stance:
I don't believe FreeBSD *needs* to replace init.

However, I think there's opportunity for improvement there. And I don't even believe that boot speed is the major potential win out of it (although it would be nice). My angle is that currently there is a multitude of different daemons/scripts (init, inetd, cron, etc.) to start/stop services depending on different circumstances.

In my view, it makes sense to streamline all those different methods of service start/stop scenarios into a single subsystem.

Yes, it would break x0 years of tradition/sysadmin compatibility, etc. But long term it could be worth it. With that in mind, I'd be swayed more towards something popular and not written by Lennart :D
 
Suppose eight daemons, twenty scripts, three services. Streamline init(d) is something I'd not want to attempt (XML breaking mergemaster...)... Long term, yes, but maybe because it may take years of beta testing to be proven as reliable. In my view, different scripts/daemons/services could be improved individually, and we might have more improvement in the end than the introduction of an additional facet to it all, given the limited man-hours of coding persons might wish to nominally persue.
 
Back
Top