Which distro to use? (Poll)

Which distro(s) are you completely against using?

  • Android (Very user-friendly, good app support, large userbase, but not a "full" version of

    Votes: 0 0.0%
  • BSD (Low support, few packages, bad ARM support)

    Votes: 0 0.0%

  • Total voters
    143

Binary logfiles, not a unix program in every possible sense that is a bad thing. The exception being that sysv is getting old, which is another matter to fix.

The discussion is very much already out there, but it doesnt matter so long as redhat money controls things.

And their biggest contractor isnt the goodguys.

All matters aside, for what it is, its bad. For everything else, there is plausable deniability.
There's plenty of issues.

It breaks a basic rule : If it's not broken, don't fix it. Classic init methods work.

It's intrusive. Now, there's some software which doesn't even compile without systemd.

Those two point are enough for me.

I'll add that it's made by a guy who sucks. He's behind the /media fiasco, he's behind the pulse audio fiasco, and i'm pretty sure to find more on him but I have things more interesting to do.
Thanks a bunch, guys.  This gives me some stuff to look into and think about.
 
It breaks a basic rule : If it's not broken, don't fix it. Classic init methods work
So did telegrams. Not fixing something because it isn't "broken" is a terrible rule, it prevents you from inventing entirely new things. This argument boils down to "it's different and I don't like change". It's ok to dislike things for being different, but that shouldn't drive policy. Sometimes change is important.
It's intrusive. Now, there's some software which doesn't even compile without systemd
By that definition libc is intrusive, qt is intrusive, pretty much every library that exists is intrusive. This tells me nothing.
I'll add that it's made by a guy who sucks. He's behind the /media fiasco, he's behind the pulse audio fiasco, and i'm pretty sure to find more on him but I have things more interesting to do.
You'll need to be more specific. What /media fiasco? What pulse audio fiasco? And under the assumption that these went horribly wrong how does that justify blanket rejection of everything else this guy might produce without actually investigating whether it is another fiasco or not?
 
1- When you change things, don't don't break everything to put your new idea in place.

2- Programs !!! Programs, not libraries are now tied to systemd.

3- /media came to pollute / . Years after, it's now in /run/ , which add a new pollution, and breaks programs using the old scheme. Not to mention that the drive now belongs to some particular user. What if no user is logged in ? Seriously, the guy didn't even thought about it, how clever he is ! . More than one year elapsed before a semi-official tweak came to put back media in /media .

Pulse audio, what a joke, the guy came with a brand new dependency, and hordes of morons used it for the pleasure of being hype. Now it's in every distribution, slowly being obsolete and removed.
 
1) That's not always possible. Sometimes change is good and sometimes that change means old stuff breaks. Linux has a long history of changing something and suddenly stuff breaks. It's an intrinsic fact of the kernel that at the very least you need to recompile drivers and may even need to change your module's code because interfaces are no longer the same. How long was the Pandora stuck on 2.6 because changing it broke everything? By this logic of never breaking anything we should stick with Angstrom or at the very least another softfp distro because switching to hardfp is basically going to break all existing PNDs.

2) Yes, and programs are also tied to libraries. Programs are tied to specific versions of libraries. Programs are tied to specific versions of gcc. Programs are tied to specific kernels! This is also an intrinsic fact of Linux, because sometimes things changes, and they break. Why is this specific change something to be fought against?

3) I've never had problems with /media, or /run, or pulseaudio. I recognize that pulseaudio has problems but it also solves several problems; this is not the time to get into that discussion though. Regardless, assuming /media (or /run, or whatever) and pulseaudio really are entirely poorly thought out that should have never existed in the first place, that still leaves your argument flawed in two ways

a) a person can have a million bad ideas but that doesn't guarantee the million and first idea will be bad.

B) pulseaudio was scooped up pretty quickly whereas systemd has a much longer period of adoption which suggests that the major distros are taking their time to actually think about it and coming to the conclusion that the benefits that come with the change are worth the adoption price. If you believe yourself more enlightened and the major distros are wrong you're going to need to bust out some facts.
 
1- classic init works

2- programs _can't be_ linked to the way an OS _starts_

3- ton of pple complained about pulse and /media, even more about /run

a) many "major" distros are blindly following red hat's moves for years. It's THEIR problem, not mine.
 
classic init works
So did telegrams.
programs _can't be_ linked to the way an OS _starts_
Can't? Or can and you simply don't like that?
ton of pple complained about pulse and /media, even more about /run
Tonne of people complain about everything. Literally. You would be hard pressed to find even one thing that someone didn't complain about. Just because people complain doesn't mean they're right and the thing they're complaining about is wrong.
many "major" distros are blindly following red hat's moves for years.
Whether that is true or not, that still doesn't mean that it's wrong.
It's THEIR problem, not mine
It becomes everyone's problem if ED sticks with Debian and you have good reasons why he shouldn't, but so far all you're turning out is "it's different and I don't like it because someone who has screwed up in the past thought of it".
 
Systemd is a platform that happens to contain an init system. I like it. I haven't heard a single argument against it that I thought was impactful enough for me to consider not using it.

A common platform of low-level userspace services only means better interoperability and less breakage at the higher levels. The higher you make your dependency pyramids by denying common platforms the higher chance there is you're both duplicating basic functionality and having stuff interfere with each other.

As an aside, if a library depends on a feature of systemd and an application depends on the library, does the application actually depend on systemd? If the switch from systemd to some other platform could be made without changes to the application, I'd say it doesn't.

I can disagree with some individual design decisions in systemd, but overall I consider it a huge improvement.
 
1- Telegrams were ditched for something better, init for something that sucks.

2- Many pple don't like the fact that programs are tied to the way the os starts, that sucks too.

3- Read posts vs systemd to see that tons ppl has good reasons to be vs. http://www.google.fr/search?q=systemd+sucks

4- Recently it was useless, bad at worst.

5- As long as I can run the OS i choose, i can avoid the trouble.
 
Last edited by a moderator:
1- Telegrams were ditched for something better, init for something that sucks.

2- Many pple don't like the fact that programs are tied to the way the os starts, that sucks too.

3- Read posts vs systemd to see that tons ppl has good reasons to be vs. http://www.google.fr/search?q=systemd+sucks

4- Recently it was useless, bad at worst.

5- As long as I can run the OS i choose, i can avoid the trouble.
On the other hand of the spectrum, you have people like me that installed systemd on his debians box as soon as it was installable.(I first meet systemd on .next. At first I was all like : "geez what this shit is all about, it even broke pam !!!"... then I (well atc) got it working and I saw the pandora boot time being plummed to near nothing and I was I awe. Nowadays, the main reason why my box is slower at booting then at resuming from suspend is ... the bios...

I'm all for systemd ;)
 
init for something that sucks
Says you but you have yet to give even one reason why this is so.
Many pple don't like the fact that programs are tied to the way the os starts, that sucks too
Many people don't like a lot of things. That they don't like it is not proof that it shouldn't exist. Like I said, you will probably not find anything that absolutely no one complains about.
Read posts vs systemd to see that tons ppl has good reasons to be
I can read about why others don't like it forever but that will never explain why you don't like it and why it shouldn't exist.
Recently it was useless, bad at worst
I don't understand what you are talking about.
As long as I can run the OS i choose, i can avoid the trouble
So you have evidence that something ED is planning to do is the wrong thing to do but you're not going to explain what it is because it won't personally affect you? Thanks.
 
1- I told my three points in post #39. I read about it since a long time, do the same. Oh, and begin to read my posts before commenting them.

2- Same as before.

3- Same as 1-

4- Refers to #47

5- Misinterpreting things on purpose for the sake of making endless threads is bad habit.

Systemd sucks, it's my opinion, I'm not the only one saying that. Make your own opinion.

I stop arguing here.
 
I told my three points in post #39
Yes you did, and I explained why those three points are not valid arguments.
Same as before
Same as 1-
And I keep telling you, just because someone doesn't like something doesn't mean it is actually bad. Google for "sysvinit sucks" and you'll see people complaining about that as well. This is not evidence that can be used to convince anyone to not use Debian.
Refers to #47
Yes, you were responding to #47, but it's not clear exactly what you were saying to what part of the post.
I stop arguing here
You never STARTED arguing! Nothing you've said is actually an argument. You've given your opinions several times but not a single bit of concrete evidence that your opinion should guide policy. If you don't want EvilDragon to use Debian you need to start explaining why, and not with things that boil down to the opinion that change is bad.
I read about it since a long time, do the same
You're the one making the claim, you need to back it up. If you're unable to explain it at the very least point us to something that can explain it because I have done some reading and found nothing but benefits to the switch; any complaints are all the same as yours and amount to nothing.
Oh, and begin to read my posts before commenting them
I read all your posts, I quote basically every single line in order to ensure that I'm not missing anything. Attempting to discredit me won't suddenly convince ED to drop Debian.
 
One readable critique of systemd is her: http://ewontfix.com/14/


I don't agree that the problem is unfixable, but also think that the systemd designers haven't yet understood the issue and that the risk is real (think heartbleed).
 
One readable critique of systemd is her: http://ewontfix.com/14/

I don't agree that the problem is unfixable, but also think that the systemd designers haven't yet understood the issue and that the risk is real (think heartbleed).
Too much in PID1

As said in the comments, systemd only has these in PID1

  • barebone init
  • dependency resolution logic
  • daemon start, stop and monitor logic
  • dbus interface (not daemon)
I don't consider that too much. At the very least it isn't the katamari damacy the author makes it to be. Many people claiming this seem to think all parts of systemd run in PID1. The above is the systemd platform; all else is daemons as they should be.

Restarting

Actually handled by the author in the post. The only downside he gives is some hypothetical scenario about crashing during reexec. Sure, it can happen. It probably will at some point in some experimental branch of a distro. But the feature set of the core systemd isn't THAT complex that it couldn't be kept clean for the stable branches.

In addition, given the limited scope of the stuff actually inside PID1 it will probably be updated fairly seldomly after the infant stages. After that it's all just restarting daemons.
 
Last edited by a moderator:
What is this about systemd requiring complete core dumps?

"Sadly, systemd became pile of everything they manage to throw in: in recent versions, even core dumps are handled by systemd's journalctl, where dumps are (ready for this:) stored _in_ journalctl database, _without_ option to be removed. Now imagine firefox or libreoffice crashes with 2-3 GB core dump."

Is that insane or am I misunderstanding something?

EDIT: after some googling https://bbs.archlinux.org/viewtopic.php?id=161393 it appears you can disable the coredumps. There are people running out of memory.
 
Last edited by a moderator:
Just to say I know nothing about these poll options; so not voting (obviously). However I just wanted to say something easy to use would be nice and often the things can make a Linux OS easy is just the small things (comes with menus/panels/etc. that link to the Pandora utilities, option to start SSH, USB host, etc.) - we don't want to have instructions like 'chmod file /bla/bla/ssh/allowed with permissions 0xbla in order to enable SSH'. I'm sure this must be obvious; that said it seems some versions of Linux ship where by default you have to drop into the terminal regularly - this (to me) seems pretty insane for a desktop; but on a handheld where the keyboard isn't as nice to use, I'd say it is nice to not have to rely on issuing commands.

I think to a bunch of people it is probably more the Window Manager, icons/desktop graphic, utilities/menus that will impact what they think of the Pyra. Probably further down the road they might appreciate other elements of a distro, but ultimately you find me someone who says distro X is the best, I'll find you someone who disagrees. Finally; it is nice being able to grab/install packages easily (apt-get install gcc - or whatever), obvious PNDs are great for providing builds of software, but it is nice to have a system that makes grabbing other stuff easy.
 
We just have to remember that the OS we choose for the Pyra is the one everyone has to deal with / support.  Hence the thought put into this.  

-Glyph Reader
 
Back
Top