- Site menu:
- Latest Discussions
- Latest Newswire
- Archives
- Submit Story
- Story HOWTO
- Syndicate
- E-mail Alerts
From next release onwards, Debian is tied to systemd
|
|
|
Comments (14)
> It's using systemd, but I'm pretending to be a user and deliberately not noticing.
You might like the link LXer just posted this morning to http://uselessd.darknedgy.net/ then. :)
Yeah, I've had to do the new kernel thing to get hardware recognized before. It's always fun.
You might like the link LXer just posted this morning to http://uselessd.darknedgy.net/ then. :)
Yeah, I've had to do the new kernel thing to get hardware recognized before. It's always fun.
I read that and laughed. :^)
Word of warning: it's rated R for language.
But yeah.
But yeah.
Personally I think changes like the one to grub are good thing. Users who don't understand things want less confusion and users who do know what is going on can still go looking for the things that are now neatly tucked away.
It is like getting your house ready for a party - you don't throw away all of the thing you use, you just put it out of sight for later/when you really need it.
~Jeff
It is like getting your house ready for a party - you don't throw away all of the thing you use, you just put it out of sight for later/when you really need it.
~Jeff
Debian adopting systemd is good. Because that ensures a sizable new chunk of non-Red Hat developers working on it. Despite some weird rants to the contrary, there are no Red Hat employess on the Debian Technical committee,and I don't know of any on any of the Debian committees. Though even if there are it doesn't mean that Red Hat rules Debian.
It's just me, I know.
I was not happy when the boot messages were simplified. I liked reading all the boot messages on my first Linux box, which scrolled by slow enough for me to actually read them.
I also drive a stick.
I was not happy when the boot messages were simplified. I liked reading all the boot messages on my first Linux box, which scrolled by slow enough for me to actually read them.
I also drive a stick.
Fearsome Bob,
Just in case I misinterpreted your words, could you be referring to a manual drive transmission in your automobile / truck / cycle / etc. ? If so, it doesn't mean much, since I have a five forward gear unit myself whereas I would have liked to had an extra gear or two to keep me more occupied.
If it's the latter, please delete the Frearsome.
As always,
YBT
Quoting:I also drive a stick.Wow, and it's not even October. You mean a broom ... do you go whole hog and don a pointy hat too?
Just in case I misinterpreted your words, could you be referring to a manual drive transmission in your automobile / truck / cycle / etc. ? If so, it doesn't mean much, since I have a five forward gear unit myself whereas I would have liked to had an extra gear or two to keep me more occupied.
If it's the latter, please delete the Frearsome.
As always,
YBT
@tuxchick
Ya' know... I've never really trusted optimists :-P
But, actually... that's a pretty interesting perspective.
Ya' know... I've never really trusted optimists :-P
But, actually... that's a pretty interesting perspective.
I put Teamviewer on it last night, to make sure that my Mom has access to my "tech support" if needed. :^)
Using the .DEB install rather than a generic binary, Teamviewer registered a service with systemd. Side by side I had my sysvinit system, so I looked at the differences.
systemd certainly seems more complex, with more files in more places for the same service. It's not clear how to disable it if I wanted to.
But then, with sysvinit, is it "obvious" that renaming the entry in /etc/init.d/ stops it from being automatically executied, while still being available for manual launching?
Or is it just familiarity?
As has been said, the only intuitive interface is the nipple. Everything else is learned.
Using the .DEB install rather than a generic binary, Teamviewer registered a service with systemd. Side by side I had my sysvinit system, so I looked at the differences.
systemd certainly seems more complex, with more files in more places for the same service. It's not clear how to disable it if I wanted to.
But then, with sysvinit, is it "obvious" that renaming the entry in /etc/init.d/ stops it from being automatically executied, while still being available for manual launching?
Or is it just familiarity?
As has been said, the only intuitive interface is the nipple. Everything else is learned.
Quoting:But then, with sysvinit, is it "obvious" that renaming the entry in /etc/init.d/ stops it from being automatically executied, while still being available for manual launching?
It might not be obvious, but it's certainly easy to explain - "as root/sudo rename the link from S92SomeService to s92SomeService and it will no longer start automatically". Tell me how to do the same in SystemD...
> ...as root/sudo rename the link from S92SomeService to s92SomeService and it will no longer start automatically
With Slackware, I just make the script non-executable, and it doesn't run. To make it automatically execute again, I just make it executable.
With Slackware, I just make the script non-executable, and it doesn't run. To make it automatically execute again, I just make it executable.
That would work as well.
I like the link name change for the simple reason that it's easy to find, and that way I don't lose the intent of the script (e.g. "S" versus "K"). But again, tell me how to do exactly the same thing in SystemD - not that you are arguing in favor of SystemD.
I like the link name change for the simple reason that it's easy to find, and that way I don't lose the intent of the script (e.g. "S" versus "K"). But again, tell me how to do exactly the same thing in SystemD - not that you are arguing in favor of SystemD.
I take it a step further:
/bin/chmod -x /usr/bin/something
Never mind the service control script in /etc/init.d or whatever. Odds are, the service control script launches something from /usr/bin. And it should be checking that /usr/bin/whatever is executable before executing it; if you see a "cannot execute" or whatever, that there's some sloppy scripting.
/bin/chmod -x /usr/bin/something
Never mind the service control script in /etc/init.d or whatever. Odds are, the service control script launches something from /usr/bin. And it should be checking that /usr/bin/whatever is executable before executing it; if you see a "cannot execute" or whatever, that there's some sloppy scripting.
Post a comment
A free account is needed to post. Write your comment here first: your text is kept in this browser while you sign up or log in, and is waiting for you when you come back.
Your message:Markdown: **bold**, *italic*, [text](https://link), - lists, > quotes, $x^2$ for math. Formatting help
Sign up and post (it is free) or Log in and post
So close. So very close.
First I tried Debian Stable, Wheezy. It installed fine, and ran, but there were things that "just didn't work". Like sound, wifi and the USB3 port.
Compiling the 3.16.3 kernel solved those. All hardware recognized, all working, hooray.
Then I tried playing a movie. This is important.
CPU usage went through the roof. Video was choppy, Xine reported an excess of dropped frames.
A little Google-fu later, it was clear that while the Intel video chip was being recognized, the MESA and GL software wasn't new enough to utilize it.
After s/wheezy/jessie/ and apt-get dist-upgrade, still with the 3.16.3 kernel, a 720p movie is using 30% cpu, rather than 180%, not a dropped packet in sight.
It's using systemd, but I'm pretending to be a user and deliberately not noticing.
In that same vein, the obfuscation of things, the isolation of users from their systems, I notice that the GRUB boot for Jessie doesn't present the user with the list of installed kernels by default. There are now only two lines on the boot screen, "Boot Debian Linux" and "Advanced".
Under "Advanced" is the formerly standard list of installed kernels along with their diagnostic counterparts.
I do not like this tendency toward hiding things.
A note of interest: The last laptop I built for Mom, an Acer which last Wednesday had a total screen failure which inspired this new machine's purchase, I had to do pretty much the same thing, installing Debian Testing (which ever that was) in order to recognize all the hardware.
I guess it's just me.