Announcement

Collapse
No announcement yet.

Debian Developers Decide On Init System Diversity: "Proposal B" Wins

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

  • starshipeleven
    replied
    Originally posted by NotMine999 View Post
    I agree with the comments about computers that could be bought back in the late 1980s and 1990s. You got books of documentation, sometimes just 1 and sometimes a few. Those books were very informative, and some still are. Nowadays the older young ones look at books and ask, "Where do I put the batteries?" while the younger young ones ask, "Where do I plug in the charger? And where is the charger?"
    Why people post this "ye olde times" bs?

    The people that needed manuals back then still need them now, it's just that now these people are now called "IT guy" or "power users" while back then they were the whole userbase.

    The pressure to drop a manual and make "intuitive" interfaces to replace them was to expand the userbase to mass market where most people won't want to read a manual to program a PC to do some basic task to do the basic task.

    It's not entirely a wrong thing per-se, as long as the interface is done well. The issue is that many times it isn't, and some service or troubleshooting info is important for IT people in the field.

    Leave a comment:


  • oiaohm
    replied
    Originally posted by NotMine999 View Post
    And with the advent of that change most maintainers involved in systemd-based distributions have lost the skill and ability to debug shell scripts.
    The ablity to debug shell scripts was long gone from maintainers well before systemd. http://www.linuxfromscratch.org/lfs/...ts/apds02.html You are ignoring the existence of /lib/lsb/init-functions

    So init scripts have not been written in plain old shell script for over 20 years now. Instead you have basically every init script in sysvinit, openrc and upstart calling /lib/lsb/init-functions or it past name results in all those functions in there shoved into the environmental variable storage that bleeds across when services are started so meaning you are not memory effective. Of course the init script is writing in mostly LSB function calls so the person who writes the init script really does not understand how to debug shell script at all.

    Basically its not most maintainers involved in systemd-based distributions don't know how to debug shell scripts. The reality is most maintainers is all distributions no matter the init system they use don't really know how to debug shell scripts. Systemd distributions are not a special case.

    Shell script has been a horrible round peg square hole for service management patched over by even more shell script that still don't fix that its a round peg in a square hole instead add even more creative ways to screw it up silently

    Even if you look at the bsd init solution you will see another include this file to provide basic functionality so you don't have to know how to debug shell script. So this lack of maintainer knowledge to debug shell scripts even extends to your BSD based distributions.

    So the idea that init scripts run by shell script means maintainers understand shell scripts is a totally bogus idea. The one who write the assist shell script knows shell script the remainder are lambs following the flock and hoping it works. This is why systemd doing this stuff in C I don't see a large problem with this way it does not leak into the environmental space and the other maintainers really did not have the skill to work on the master part anyhow in most cases.

    Leave a comment:


  • starshipeleven
    replied
    Originally posted by NotMine999 View Post

    One of the few times I completely agree with one of your comments, so I clicked the "Like" button.
    Thank you, good sir.

    Leave a comment:


  • jason.oliveira
    replied
    Looks like the shills found something to latch-on to: "At least Devuan thinks they can't keep up".

    It isn't like there's a list of non-SystemD-using Debian-derivatives the Devuan devs could steal from. No sir, This is the silver lining on the dark cloud that proves this loss for SystemD really isn't a loss!

    Leave a comment:


  • Britoid
    replied
    Originally posted by NotMine999 View Post

    And with the advent of that change most maintainers involved in systemd-based distributions have lost the skill and ability to debug shell scripts.

    Based on your statement, upstream does all the work for these lazy maintainers. So what do these lazy maintainers actually do for systemd-distributions? Do tell.
    You're almost saying making it easier to mantain packages and lowering the needed skills is a bad thing?

    Mantainers will still need to package it into the native package format and ensure dependencies resolve correctly.

    Leave a comment:


  • Britoid
    replied
    Originally posted by ThiagoCMC View Post
    So, will Devuan die now?

    "If the Proposal D by Ian Jackson will not pass, Devuan will die."



    What's next?
    If Debian drops the support for any other init system but systemd, I believe we won’t be able to keep up with the legwork needed to support all other init systems.
    LMAO. So they won't do it themselves but expect Debian to?

    Leave a comment:


  • Ironmask
    replied
    Originally posted by ThiagoCMC View Post
    So, will Devuan die now?

    "If the Proposal D by Ian Jackson will not pass, Devuan will die."



    What's next?
    What else? A hard fork of OpenBSD

    Leave a comment:


  • NotMine999
    replied
    Originally posted by starshipeleven View Post
    No goddamnit this isn't a "victory". This is "we keep doing what we were doing until now" which means the issues that pushed them to actually vote and decide to do something will remain (namely having crappy support for both systemd and other inits instead of having GOOD support for a single init)
    One of the few times I completely agree with one of your comments, so I clicked the "Like" button.

    Leave a comment:


  • NotMine999
    replied
    Originally posted by Britoid View Post

    systemd unit files are often supplied by upstream

    rarely any systemd units in the last 5 years use shell scripts, I guess you haven't used systemd in a while.
    And with the advent of that change most maintainers involved in systemd-based distributions have lost the skill and ability to debug shell scripts.

    Based on your statement, upstream does all the work for these lazy maintainers. So what do these lazy maintainers actually do for systemd-distributions? Do tell.

    Leave a comment:


  • NotMine999
    replied
    Originally posted by stormcrow View Post

    For anyone that was actually AROUND back then and used them, they were extremely usable and widely used. Why? Because unlike today most computers and operating systems came with EXTENSIVE written dead tree manuals that explained how everything worked down to pinouts and circuit diagrams. Ditto for the operating system, firmware interfaces, and any built in or purchased compilers and interpreters. My C-64 came with a manual that explained the board expansion ports, their use, pinouts, and registers. It also detailed how to write programs for the built in BASIC interpreter, described system registers, etc. All of the higher end systems came with both digital and dead tree documentation in multiple volumes describing most of the functionality. The man pages on Unix systems was extensive and generally accurate. So yes, these systems were extremely "usable"!

    So stop trolling about usability when you're comparing apples to oranges. These days most computers come with bupkiss and you're expected to "figure it out". It's really no wonder general purpose computing is in the shape it is these days, because no one knows how anything works, and yes this includes Linux with it's usually out of date, missing, or inaccurate "documentation" - and no code never does and never will "document itself". That's a trope for lazy programmers that don't want to write proper documentation.
    I agree with the comments about computers that could be bought back in the late 1980s and 1990s. You got books of documentation, sometimes just 1 and sometimes a few. Those books were very informative, and some still are. Nowadays the older young ones look at books and ask, "Where do I put the batteries?" while the younger young ones ask, "Where do I plug in the charger? And where is the charger?"

    Those old computers worked from a command line. Many had BASIC onboard in ROM, ready for your use. You learned to use computers that way or you sold the thing and returned to pencil & paper. The point & click GUI interface came about with the Apple ][ family of computers. The Commodore C-64 / C-128 family eventually got a GUI of sorts. Amiga got a ready usable GUI from Day 1. Around that time the IBM PC got Windoze. GUIs brought more users to computers. And you still got dead tree manuals to read and self-educate. Nowadays the users can't function without point & click, gigabytes of preloaded crapware, almost useless preloaded, but more commonly online manuals. "Use the command line? PHOOEY!" [Thank you Nero Wolfe on TV for making "Phooey!" part of my vocabulary.]

    Personal computer user communities back then were actually quite friendly and quite helpful. Some only met monthly while others met weekly. People would show off the latest software that they bought or discuss the latest magazines that focused on their specific OS. Sometimes, if you were very lucky and knew the right people, you might get a guest speaker from a local shoppe or maybe a manufacturer's rep dropping by for a chat and possibly to show off hardware. After the meeting some would get together to lift a pint, grab a bite, and continue the chats.

    As online BBS began to appear they would specialize in a specific OS, usually because the SysOps or BBS owner(s) knew that OS. A few offered chat spaces for different OS. I don't remember "flame wars" back when I was a SysOp as folks seemed to stay with their own OS crowds. The attitude back then seemed to be, "Why bother knowing about another OS when I've got full hands learning what I have now?" I honestly think "flame wars" brewed up with the advent of Internet access and folks having nothing better to do than to argue (more like bike shedding) unresolvable points. And as I have seen in this thread, those "flame wars" and that "bike shedding" have not gone away.

    This thread very early on reached it's "Phoronix Moment", that point in a Phoronix thread when you think you are reading Slashdot. The topic of conversation seems to have spun out farther than Pluto's orbit.

    Leave a comment:

Working...
X