Announcement

Collapse
No announcement yet.

Debian Moves Closer To Voting On Proposals Over Init System Diversity

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Delgarde
    replied
    Originally posted by coder View Post
    That's my main gripe with it - that it defies the concept of modularity. They should've focused on standardizing a set of interfaces, so that different services could be swapped out for various duties.
    They did — the interfaces are all well documented, and they're amenable to making changes to help others provide alternative implementations.

    Only problem is, nobody seems to want to... many people complain about the lack of alternative implementations, but there have been very few attempts to create one, and even fewer that have gone anywhere. Turns out that while complaining is easy, committing to build and maintain code is much harder...
    Last edited by Delgarde; 18 November 2019, 10:45 AM.

    Leave a comment:


  • danmcgrew
    replied
    Systemd - Progress Through Complexity
    OCS-Mag; Updated October 19, 2016

    http://www.ocsmag.com/2016/10/19/sys...gh-complexity/

    Leave a comment:


  • starshipeleven
    replied
    Originally posted by NotMine999 View Post
    And I'm not vaping here. The boot time results for the systemd versions come straight from the "systemd-analyze blame" command and point straight to a systemd service loading & failing.
    Yes you are vaping.

    systemd services are created by the distro, not by systemd upstream.

    "systemd-analyze blame" is a diagnostic tool to find what service file is wrong, because upstream knows full well that someone somewhere will write bs in their service config file, and has made a tool that allows you to find the culprit in seconds.

    And you, evil genius, not only you don't use it to fix the issue, but somehow think that using it makes your point more valid. Of course it's a systemd service that blocks boot, every system service is using systemd in that distro.

    The sysvinit-based distributions would load to a LxQt desktop login prompt in 15 seconds.
    Yeah, but when something breaks there is no sysvinit-analyze blame that points to the culprit, isn't it?

    Leave a comment:


  • F.Ultra
    replied
    Originally posted by NotMine999 View Post
    In my experience I find that systemd still has lots of room for improvement.

    Just last night I was experimenting with the installation of various lightweight Linux distributions on an older mini PC that uses 4GB of RAM and an Intel D2550 CPU.

    The intent is to load up to a simple windowed desktop state. My preference for lightweight desktop environments is LXDE & LxQt over XFCE based solely on my own past experiences. The ultimate use of these mini PC machines will be a fully automated (no human intervention necessary) display system that runs in a web browser interface.

    The distributions that used systemd had the slowest boot times on this hardware compared to distributions that used sysvinit. systemd would take 60 to 70 seconds to load to a LXDE desktop login.

    And I'm not vaping here. The boot time results for the systemd versions come straight from the "systemd-analyze blame" command and point straight to a systemd service loading & failing.

    Every systemd-based distribution experienced issues loading a service "systemd-random-seed" or something worded like that it. That service never loaded; always showed "failed" when I typed the "systemctl" command by itself. That hanging service also caused the SSH service to "take forever" to load.

    The sysvinit-based distributions would load to a LxQt desktop login prompt in 15 seconds. SSH was available by the time the login prompt was displayed.

    So which style of init do you think I would choose for this older mini PC? I'll give you 2 guesses...
    Remember that you are comparing distributions now and not just systemd. Googling for this service +failed gives some hint that certain distributions fail to set /var/lib/systemd/random-seed as writeable on some configurations but not sure if that is the same problem that you have encountered.

    Leave a comment:


  • moilami
    replied
    Originally posted by Terrablit View Post
    Looks like it's time for another rant.



    Actually, the end-user benefit of choice is a common fallacy. Consumers always claim to want choice, true. But it's been shown that consumers are actually less satisfied as the number of choices grows. They get subconsciously hung up on the opportunity cost, wondering if their choice is the "best" choice. They always feel like they're missing out on something. And when none of the choices matches exactly what they think they want, they get even less satisfied because it feels like all of the options are bad. This is economics 101. But, given how far removed most FOSS and linux enthusiasts are from even the idea of economics and having to pay for a lifestyle, it's not surprising that you don't seem to understand.

    This is easily seen in the amount of time people spend tweaking and trying out new things in their distro (or different distros). At the beginning, it's fun and new. Then it takes a lot of resources and it's not fun. Most people who have a hobby of tweaking or optimizing eventually pare it down to a very limited category of things. Like rebuilding one car, renovating a house, or one application workflow.

    After a while, it's a chore to evaluate all the options, so people just go with whatever they're comfortable with or whatever seems the best fit at the time. Later on, they avoid re-engaging in consumer selection. This can also be seen in tech circles. Administrators will choose the applications they know how to work with, even if they're not the best, simply because they don't want to evaluate again. Everybody kvetching about change and talking about the Unix philosophy fall into this category. It's been demonstrably proven that the Unix philosophy isn't the best user experience at all. It's arguable that it might have been back in the 1970s. But certainly not anymore. It's just flexible enough to not be the worst experience, since you can still get things done by duct taping a blow torch to your chainsaw when all else fails.

    Similarly, developers will choose the libraries and APIs they know rather than the best ones. And they don't constantly look for new options. Instead, they settle into complacency based on the productivity trade-off of an arbitrary point in time.



    So, no, Linux is not about choice. Life is not about choice. And please everyone fuck off with that silly idea. The only choices I want to make are choices that influence my personal happiness. Choices should be restricted to things that matter. There shouldn't be an available choice unless there's sufficient ROI for the cognitive load generated by having to make a decision. Imagine a visual novel where every click is a choice. Even banal ones like whether you say the plot dialogue line or not. That'd be the worst game ever. You'd have no time to engage the story.

    The idea that everyone needs to have different options for basic operating system plumbing is the dumbest idea that ever shat itself out. Operating system plumbing should be as invisible as possible. Nobody needs to see and interact with every inch of the pipes in the bathroom. You only care about the sink, shower, and toilet. And you certainly don't want to manually push the shit through every inch of the pipes.

    That's a major goal behind most distros moving to systemd. It's tackling *all* the problems, and it's reducing even maintainer exposure to init internals. There's hiccups, yes. Just like there were with the previous "solution". But eventually almost no one's going to need to dick around with this bullshit that's plagued us for 3 decades and we'll all be a lot happier.
    I don't buy that. It is the same kind of talk what was quite common in 15 years ago how technology is bad because people are depressed. Had the technology been removed and people moved back in time 500 years most of the people would had cried out loud their momma.

    While phenomenons you described exist the conclusions of the reasons behind them are invalid. If choice would be removed and you were back to Ford Model A, with about 2 variations of each gadget, people would be hell annoyed about that there is no choice because one size does really not fit all. But the good thing would be that enormous economical boom would happen when people would start up companies to satisfy the demand of choice in markets.

    Just because some try to buy happiness by consumerism, and are doomed to fail no matter what they buy, does not mean that the reason for their bad feelings is overwhelming choice, making even their attempts to buy happiness hard. They are the problem themselves, the choice is not the problem.

    Life is about choices right away when you can make them. It is a sequence of choices.

    Leave a comment:


  • starshipeleven
    replied
    Originally posted by NotMine999 View Post
    The snobby "whatever is old I don't care about" attitude.
    Wrong, it's about acting like you live in the same decade as everyone else.

    This is 2019, if you want your project to actually be seen and adopted by potential users and form a decent community to receive contributions you have to do like we do in 2019.

    I'm using fucking github (i.e. git VCS, bugtracker and contribution management) for a bunch of utility bash scripts and a rEFInd theme. It took me 10 minutes to do so.

    This guy's idea of opensource software development in 2019 is posting a tarball of plain source that is NOT kept with a VCS on a static site that was written with a text editor?

    And I'm supposed to trust this guy that is still clearly partying like it's 1999 to write a critical system component like an init system?

    Over 25 years ago
    was a very different world

    Ah ok I see what you did.
    Kernels are always executable binaries. CPU does not execute ascii text

    So you would be in favor of a proprietary binary-only blob of kernel
    No

    Leave a comment:


  • NotMine999
    replied
    Originally posted by starshipeleven View Post

    No you are posting bullshit. What was ok 20 years ago is not OK now as the world has changed since then. Every half-assed hobby project TODAY has a github or gitlab repo with issues and PR support or even a self-hosted minimal git server and a basic mailing list.
    Failing to do so will mostly get the "eeeh I'll pass" reaction from most.
    Oh how quaint. The snobby "whatever is old I don't care about" attitude.

    Over 25 years ago I worked with scientists from the labs of a telecommunications company on technology displays that utilized the WWW as it was back then. Skilled webpage authors knew and understood the ins & outs of WWW coding as it was back then. Webpages were written in whatever helpful and handy text editor that was available on the target platform. The typical servers in those days were using Sun hardware, so using vi or emacs to edit webpage code was not uncommon.

    As George Santayana once said:“Those who cannot remember the past, are condemned to repeat it.”

    https://www.goodreads.com/quotes/634...mned-to-repeat

    Originally posted by starshipeleven View Post
    Also a kernel is not "plain text files that are standardized and easy to parse for anything." That's configuration files, a kernel is supposed to be a binary.
    Ah ok I see what you did. So you would be in favor of a proprietary binary-only blob of kernel where you have no privilege to inspect the source code. Got it.

    Leave a comment:


  • NotMine999
    replied
    Originally posted by Terrablit View Post
    Looks like it's time for another rant.
    Ahh..the Phoronix moment. When a Phoronix forum thread turns into a whining Slashdot rant.

    Leave a comment:


  • NotMine999
    replied
    In my experience I find that systemd still has lots of room for improvement.

    Just last night I was experimenting with the installation of various lightweight Linux distributions on an older mini PC that uses 4GB of RAM and an Intel D2550 CPU.

    The intent is to load up to a simple windowed desktop state. My preference for lightweight desktop environments is LXDE & LxQt over XFCE based solely on my own past experiences. The ultimate use of these mini PC machines will be a fully automated (no human intervention necessary) display system that runs in a web browser interface.

    The distributions that used systemd had the slowest boot times on this hardware compared to distributions that used sysvinit. systemd would take 60 to 70 seconds to load to a LXDE desktop login.

    And I'm not vaping here. The boot time results for the systemd versions come straight from the "systemd-analyze blame" command and point straight to a systemd service loading & failing.

    Every systemd-based distribution experienced issues loading a service "systemd-random-seed" or something worded like that it. That service never loaded; always showed "failed" when I typed the "systemctl" command by itself. That hanging service also caused the SSH service to "take forever" to load.

    The sysvinit-based distributions would load to a LxQt desktop login prompt in 15 seconds. SSH was available by the time the login prompt was displayed.

    So which style of init do you think I would choose for this older mini PC? I'll give you 2 guesses...

    Leave a comment:


  • starshipeleven
    replied
    Originally posted by archsway View Post
    starshipeleven



    A usenet post and tarball on a ftp site? What about mailing list, bug tracker and git server.

    Might be great, but it looks like a hobby project of a single guy.

    Don't take me wrong, I wouldn't mind seeing a distro built around it and taking it for a spin, but eeeh as it is it does not inspire much confidence as-is.

    I don't understand what is hard to do in a kernel. It's plain text files that are standardized and easy to parse for anything.

    More niche stuff none really cares about. I don't even know if it still ships the BSD packages at all.
    Ah ok I see what you did.

    No you are posting bullshit. What was ok 20 years ago is not OK now as the world has changed since then. Every half-assed hobby project TODAY has a github or gitlab repo with issues and PR support or even a self-hosted minimal git server and a basic mailing list.
    Failing to do so will mostly get the "eeeh I'll pass" reaction from most.

    Also a kernel is not "plain text files that are standardized and easy to parse for anything." That's configuration files, a kernel is supposed to be a binary.
    Last edited by starshipeleven; 17 November 2019, 09:08 PM.

    Leave a comment:

Working...
X