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.
Shall we fork Fedora?
41–49 of 49 posts
Re: Shall we fork Fedora?
#42Earlier 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/
Re: Shall we fork Fedora?
#43I 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.
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?
#44Earlier 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…
Debian patched Wheezy for Shellshock within hours as well. You should verify that your box has the Security repository enabled.
Re: Shall we fork Fedora?
#45Trying to work out which linux dist to switch to. Obviously one that doesn't use systemd. So what choices do I have?
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?
#46I 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.
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?
#47I 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?
#48What 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…
Re: Shall we fork Fedora?
#49love 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…
You could create targets for all of your states, and use a small daemon to switch between them (using systemctl isolate).