Live data from Hacker News

Shall we fork Fedora?

forkfedora.org

41–49 of 49 posts

Re: Shall we fork Fedora?

#41
post #29
post #15

From the debianfork.org page, which this is apparently mocking: "Why don't you do that yourselves? We are excluded from voting on the issue: only few of us have the time and patience to interact with Debian on a voluntary basis." If you don't have the time and patience to contribute to a project like Debian, how are you planning to muster up the time and patience to run a full-on FORK of Debian?

Short answer, because I've said it before: You can't vote on Debian issues without becoming a Debian Developer; that title requires a multistep process that takes between months and years. Debian publishes the stats at nm.debian.org, and there is general agreement that the length of the process is a problem, but not on how to solve it.

I don't doubt that there's a barrier there, and it could possibly (probably?) made easier to overcome. But it still strikes me as a smaller barrier than that of having to maintain a full-fledged fork, especially one that focuses on a low-level dependency like systemd, rather than focusing on higher-level stuff like the desktop environment.

Re: Shall we fork Fedora?

#42
post #40

Earlier quoted context omitted.

> I've used Arch as my primary OS for over a year now, and I've never had any major problems. What flakiness have you experienced? I love Arch. I've been using Arch as my primary OS for over 4 years. I'm even wearing my Arch Linux hoodie at work today[0]. Every time someone mentions instability or flakiness on Arch (on HN or any other forum), I see comments like this, and it really makes me wonder - are we using the…

The usual "Arch is unstable" convinced me to put up a very simple jekyll blog [0] with all the arch related problems I run into from here on out. I've only listed the last 2 problems now. As months go by the list will probably get longer and better reflect how much arch actually breaks (or doesn't) [0] https://arguggi.co.uk/blog/I-Just-Want-It-To-Work/

nice, i had one the other day where convert would take 5 seconds to resize a jpeg. i downgraded it and it was fine. i probably should have filed a bug, but i had work to do, and had already wasted enough time waiting for images to resize!

Re: Shall we fork Fedora?

#43
post #17
post #4

I rolled my eyes at the title after watching "Linux Sucks 2014" last night. I was pleasantly surprised to see an example comparison of init files.

I'm not sure it's exactly a fair comparison though; the right-hand file is shorter and simpler largely because they've split the work of the old init script across at least three files: the one shown, /etc/mail/make (which presumably now contains the messy preparatory work that made up most of the old init file), and sm-client.service. You could do that with traditional init if you wanted.

And the only thing keeping that from happening with traditional init is someone submitting a patch against the package to split up the functionality of the init script into more distinct subunits.

It's interesting to note that no patch has been submitted against the sendmail package, most likely because it's unnecessary. And the only reason that the logic was moved to separate subscripts called in ExecStartPre entries for systemd is because systemd doesn't have a language to express those things in, so they need to be subscripts in order to have that capability at all.

Re: Shall we fork Fedora?

#44
post #8

Earlier quoted context omitted.

I've used Arch as my primary OS for over a year now, and I've never had any major problems. What flakiness have you experienced?

> I've used Arch as my primary OS for over a year now, and I've never had any major problems. What flakiness have you experienced? I love Arch. I've been using Arch as my primary OS for over 4 years. I'm even wearing my Arch Linux hoodie at work today[0]. Every time someone mentions instability or flakiness on Arch (on HN or any other forum), I see comments like this, and it really makes me wonder - are we using the…

> [3] I'm running Wheezy on another machine, and shellshock still hasn't been fixed there, whereas Arch had it patched within hours.

Debian patched Wheezy for Shellshock within hours as well. You should verify that your box has the Security repository enabled.

See https://packages.qa.debian.org/b/bash.html.

Re: Shall we fork Fedora?

#45
post #11

Trying to work out which linux dist to switch to. Obviously one that doesn't use systemd. So what choices do I have?

It seems Debian may stay init-system flexible at least. So there may be an option there.

But consider FreeBSD, it may seem extreme, but if you're willing to make that move then their philosophy may be more in line with yours anyways. Their rc system is great and includes vastly simplified scripts using rc.subr, while still keeping everything as shell scripts. No bloated dbus or similar nonsense required.

Re: Shall we fork Fedora?

#46
post #17
post #4

I rolled my eyes at the title after watching "Linux Sucks 2014" last night. I was pleasantly surprised to see an example comparison of init files.

I'm not sure it's exactly a fair comparison though; the right-hand file is shorter and simpler largely because they've split the work of the old init script across at least three files: the one shown, /etc/mail/make (which presumably now contains the messy preparatory work that made up most of the old init file), and sm-client.service. You could do that with traditional init if you wanted.

One of the things which also bothers me about systemd is that it sort of "hides" things though layers of abstraction, compared to the shell scripts at least. For example, it is not immediately clear to me what effect "Type=forking" will have. It might not be so bad in this example, but it seems like this can wind up being quite complicated in some cases.

FreeBSD has a somewhat better simplification in my opinion using a common rc.subr file, which is included in many init scripts and can easily be reviewed by anyone editing an init script.

Re: Shall we fork Fedora?

#47
What a puerile attempt at trivialising someone's concerns. Why do you think a file length is important? What you are demonstrating is the very lack of control that people are complaining about. Well done, you've replaced the standard functionality with an ini file. What about non-standard functionality? Flexibility? Transparency? The logging concerns? The dbus concerns?

I think one of my biggest concerns with systemd is that there seems to be little valid debate around it. The pro-brigade mock the anti brigade with little attempt to address their concerns.

Re: Shall we fork Fedora?

#48

What a puerile attempt at trivialising someone's concerns. Why do you think a file length is important? What you are demonstrating is the very lack of control that people are complaining about. Well done, you've replaced the standard functionality with an ini file. What about non-standard functionality? Flexibility? Transparency? The logging concerns? The dbus concerns? I think one of my biggest concerns with systemd…

I have been using the tried and true ostrich technique to avoid the topic (the whole systemd debate). But honestly it feels like the file on the right is a whole lot more opaque. If (or when) it goes horribly wrong, I am not certain I would know where to start, as compared to a simple script file where I would walk it / debug it.

Re: Shall we fork Fedora?

#49
post #2

love it. i just recently switched to fedora. i was on debian, then i went to arch because debian is too outdated, and i wanted systemd. but i don't enjoy the flakeyness of arch these days, i did when i was younger, but now there's more than just me using my computer, and when i do use it, i want to use it for work, not fiddling with stuff. so when i was looking for a new distro, systemd was a requirement, there's no…

So I'll prefix this by saying that I haven't used systemd for anything important yet, but have it running in a VM to see what the impact will be when the distro's force us to switch. It seems that for the "normal" use cases (i.e. laptop running gnome+vi, server running postgres) systemd will be simpler. For embedded / single purpose applications, it seems that it will require a chunk more work. I have use cases like…

I have use cases like a) Only power the 3G module and bring up ppp when I am within certain GPS coordinates.

You could create targets for all of your states, and use a small daemon to switch between them (using systemctl isolate).

Post reply on HN