Why I dislike systemd(steven-mcdonald.id.au)

steven-mcdonald.id.au

http://www.steven-mcdonald.id.au/articles/systemd.shtml

253 comments

weland11년 전

I'm one of the people who jumped ship to OpenBSD in the last year or so. I think I first touched a Linux machine in 1997 or 1998. systemd has been part of the reasons I did that for precisely the same reason.

There is a lot of development in the ecosystem dominated by Freedesktop.org, Gnome and (to some degree) large commercial players like RedHat and SUSE. It's more efervescent than it's ever been. Fifteen years ago, I'd have been ecstatic to see so much development being done.

Yet for all this fierce code churning, there's absurdly little innovation. Even in systemd, there's a lot of focus on non-issues like booting without needing a shell, while still inventing service startup notification types because none of the gazillion startup notification types already existent can actually solve precisely the problem systemd claims it solves -- managing complex startup chains.

In the last three or four years, my Linux systems have become increasingly blackboxed, and consequently harder and harder to configure, let along debug when they stop working. Over the span of six months, a tool you just got to learn how to work with (mostly because the documentation seems to have been written by very bored and very verbose monkeys who had only a typewriter to pass the time with) becomes obsolete or is revamped to be unrecognizable. Which would be fine if that actually solved any problems. Instead, it replaces the old set of problems with a new, even more complicated set of problems that developers claim you shouldn't have, while insisting that the old problems were simply due to the old architecture and we'll have none of that now that we have this shiny new thing.

Ironically, systemd is actually one of the better pieces of software to come out of that ecosystem. No, seriously. It's decently documented and as long as you don't need anything more complex than "here, start this daemon after this other daemon started", it does its job.

If you want to peck at something, have a look at Polkit, where someone brilliantly figured out that the best way to configure policies is to write basically undebugable JavaScript code in .rules files.

pjc5011년 전

Polkit is a nightmare. And I agree with you on the churn. There was a time when Linux administration changed less frequently than Windows, round about the 95-XP-Vista era.

groks11년 전

http://smcv.pseudorandom.co.uk/2015/why_polkit/

weland11년 전

Polkit is a great idea, don't get me wrong. However:

* Like pretty much anything from freedesktop.org, the documentation is a joke.

* The security system implemented through it is next to impossible to debug. It's very easy to add "allow <this thing> to happen", but I can't do things like "ok, tell me who can mount filesystems" or "give me a list of all things that users in the wheel group are allowed to do". Normally this would be trivial to implement by parsing the rule files, except that the rules are written in JS (I have no idea why) and parsed in a particular, cumbersome order.

* Probably also as an artifact of having to execute JS code to add rules, many errors are silent, incomprehensible, or occur only when a particular action happens.

* polkit doesn't have a textual interface, it only works through D-Bus. This makes it useless for scripting.

groks11년 전

> Like pretty much anything from freedesktop.org, the documentation is a joke.

  man polkit

Looks pretty good to me. It even includes an ascii-art architectural diagram! Here's the webified version: http://www.freedesktop.org/software/polkit/docs/master/polki...

> polkit doesn't have a textual interface, it only works through D-Bus. This makes it useless for scripting.

polkit(8) and pkcheck(1) describe how to use the pkcheck program. It returns 0 on success (access granted).

> I can't do things like "ok, tell me who can mount filesystems"...

I think that's the nature of the problem domain. polkit seems to be for enforcing arbitrary rules, when the built-in rules of something like sudo can't cope. Therefore: arbitrary code snippets as rules, therefore, no introspection.

However...

> ...or "give me a list of all things that users in the wheel group are allowed to do".

  pkaction | grep mount
  org.freedesktop.udisks2.filesystem-mount
  org.freedesktop.udisks2.filesystem-mount-other-seat
  org.freedesktop.udisks2.filesystem-mount-system
  org.freedesktop.udisks2.filesystem-unmount-others

Gives a list of actions. Use pkcheck to probe for access.

weland11년 전

> Looks pretty good to me.

Ok, let's put it to a simple test :).

# pkcheck --action-id org.freedesktop.udisks2.ata-standby pkcheck: Subject not specified

<What the hell is a subject?> # man pkcheck /subject

<???>

It means to say that you have to specify a PID for which to check that. But the word "subject" doesn't even appear in the pkcheck manpage.

The synopsis also lists three possible forms for --process. However, only one of them is valid and (the developers currently think) presents no race conditions. There's a note warning that the other two are buggy, but they're still accepted for compatibility reasons, because those two (buggy) methods have been standard for years.

> I think that's the nature of the problem domain. polkit seems to be for enforcing arbitrary rules, when the built-in rules of something like sudo can't cope. Therefore: arbitrary code snippets as rules, therefore, no introspection.

I don't think it's the nature of the problem domain. The "arbitrary rules" can have a user- or group-base restriction. It's an architectural limitation that the system cannot go through the list of all currently enforceable rules and return those that match a particular user.

> However, [...] Gives a list of actions. Use pkcheck to probe for access.

The problem is that pkcheck verifies whether or not a certain process can execute a function. You can sort of hack it to do that, but it's not always effective.

By the way, the reason I need to be able to do it is the following gem:

> There is no guarantee that a function registered with addRule() or addAdminRule() is ever called - for example an early rules file could register a function that always return a value, hence ensuring that functions added later are never called.

This is extremely unpleasant, because you can (I have) run into problems of the following sort:

* I insert a rule with a particular priority that gets registered and runs. Ok, no problem.

* Later on, <some buggy software> inserts another rule which returns a value, thus terminating the rule chain before my rule gets to run.

Now all I find is that my own rule is not enforced, but I can't tell why that happens. There's no trivial way to trace the rule chain.

It also doesn't help that errors in rule files seem to go unreported. If you type "heel" instead of "wheel" for a group name, the whole thing will happily carry on, or at least I haven't yet figured out how to look for those errors.

pjc5011년 전

From the bullet points:

Fine-grained access control needs domain-specific understanding

This also applies to the user trying to configure it. For all the reasons listed in "weland"'s sibling comment, this is hard to learn. If something doesn't work in polkit, and you're not completely familiar with it, it's very hard to make it work.

digi_owl11년 전

On that note:

https://www.techdirt.com/articles/20150615/11565531344/repor...

digi_owl11년 전

I can't tell the difference between sudo and polkit, except that the latter comes with some XML based presets and can be talked to via RPC (dbus).

groks11년 전

The difference appears to be that the sudoers file supports the finite set of access checks the authors of sudo anticipated. If you need something more elaborate than that, write arbitrary javascript to the polkit api.

digi_owl11년 전

> There is a lot of development in the ecosystem dominated by Freedesktop.org, Gnome and (to some degree) large commercial players like RedHat and SUSE.

Yeah, i've been thinking the same recently.

The current development above the kernel seems to either be from the desktop down, or from the point of view of managing 1000s of headless instances in a "container" farm.

This with a side-order of Windows-isms demanded from corporate/government clients looking for a way to get away from MS while retaining their centrally controlled fine grained access control.

anon3_11년 전

> I'm one of the people who jumped ship to OpenBSD in the last year or so.

Ha. FreeBSD here.

And so long as you get the right hardware, I find BSD to be far simpler than linux distributions out there.

Ports? Beautifully elegant and simple. Configurable. Magnitudes easier than configuring rpm/debs.

Getting a package approved in debian? Alioth? No offense, the wiki, all these pages on the debian website - they have no concept they have of "Handbook", in the sense FreeBSD has. It's so adhoc, they're healthy, but they're in denial about how hard they make it for new people. By the time you've taken to time to learn Debian's dev warts, you're apart of the convent and no longer care about fixing the onboarding problems.

But to be fair. I have day to day gripes with FreeBSD just because we're short on the manpower Linux distributions have in excess:

On FreeBSD 10.1, chromium crashing easily, settings doesn't work. Firefox just clogs up and stops working. No skype (CURRENT will be in a better position to since epoll support has been added). No Dropbox (as of now, we don't have inotify, and kqueue may not be able to handle it, don't quote me on that).

I do my 90% of daily routines simpler and better on FreeBSD. If only Google / Mozilla (with all the resources they have) gave someone who could work to fix this stuff.

weland11년 전

I've occasionally used {Net|Free|Open}BSD over the past few years (in fact, I think my Jornada in the back of the closet still runs NetBSD). I kept sticking to Linux partly because I was using it at $work, partly because it was simple enough and I'm kindda lazy. But yeah:

> I find BSD to be far simpler than linux distributions out there.

The way OpenBSD handles WiFi configuration is a good example of this. Want to connect to a wifi network? ifconfig <interface> <ESSID> <passphrase>. If you need some other fancy flags for those 0.1% of hotspots in the world, you can do those, too (also through ifconfig) but it's that simple.

In contrast, after everyone agreed that wpa_supplicant is probably what happened after Stalin's ethereal spirit had mad sex with Hitler's ethereal spirit and their ethereal baby was incarnated, what did we do to alleviate things in Linux land? Why, we wrote NetworkManager, of course! Conservatively, 90% of today's deployments of NetworkManager exist because no one can figure out how to set up wireless without it, and we put up with its crap because wicd is waiting for us at the other end.

Better yet, this is all nicely documented in the manpage. If you search for "wireless" in ifconfig's manpage, you find out all you need to know. Just for fun, compare that to man networkmanager.

> On FreeBSD 10.1, chromium crashing easily, settings doesn't work. Firefox just clogs up and stops working. No skype (CURRENT will be in a better position to since epoll support has been added). No Dropbox (as of now, we don't have inotify, and kqueue may not be able to handle it, don't quote me on that).

I haven't had crashing things on OpenBSD, but yeah, a bunch of things don't work. Fortunately, they're things I don't use. If I ever need them -- OH THE HORROR AND THE BLASPHEMY -- I have a Windows laptop, which for all intents and purposes is by now about as closed and as hard to wrestle with as Fedora, but at least it doesn't hopelessly break every six months. There are Linux-only things that I sometimes need because at some point between 2003 and 2013, "portable" ended up meaning "we can probably work if you have bash in a non-standard location but that's about it" (eh, Yocto?) for which a cheap VPS is more than enough. When it breaks, I don't have to spend days trying to find out exactly what part of PolicyKit broke or where my devices are mounted this week -- I just wipe everything and reinstall.

bad_user11년 전

While I don't disagree that wpa_supplicant has been spawned from hell, I find it strange that the existence and popularity of NetworkManager is given as a clue for why {Net|Free|Open}BSD is better. You know, connecting to a WPA protected Wifi network is not the only problem users have. For example, another one would be connecting to a VPN, a task that NetworkManager greatly simplifies, assuming that such integration is available of course (e.g. if you think connecting to a Wifi network is problematic, try connecting to a L2TP over IPSec VPN).

There's also the issue that the simplicity exposed in your example is a little misleading. Will the system persist that command and re-execute it on boot? Will it remember my previously used Wifi networks and connect automatically should I want that? How can I view the available Wifi networks in range? Being able to connect to a Wifi network using a simple ifconfig command is great, but the notion that your 80% of use-cases is the same as everybody else's 80% is misguided at best.

> If I ever need them -- OH THE HORROR AND THE BLASPHEMY -- I have a Windows laptop, which for all intents and purposes is by now about as closed and as hard to wrestle with as Fedora

And therein lies my problem with your entire comment. It's not that I disagree with your usage patterns, but I disagree with your assertions in light of these usage patterns. So you're saying that xBSD is simpler / better, yet you can't use it on your laptop, as it lacks things you need. Well, no shit.

mpdehaan211년 전

Watching Linux distros push essential functions into the Desktop layer (power management, network management, etc) without good CLI equivalents limited my window manager choices in the past. This was mostly because the Gnome/desktop folks at RHT were willing to do the work, and there wasn't anyone else to do it, and then that's what happened.

What this did though is pretty much make it where Gnome was the only usable option, or you had to fight a good deal to make something else usable.

as Fedora's desktop choices seem particularly rough, and have pretty much left me with using Linux in VM environments from Macs.

This is very quickly becoming the default for most developers I know, with a few exceptions here and there.

I don't think systemd hurts too bad in the service statup environment once you rememer the commmands are all different, but I don't like what it's doing with creeping into other areas, like what it does with logging.

icebraining11년 전

I don't know about power management, but I've used nmcli for network management without much difficult, and nm-applet works outside of Gnome as well. I've never felt constrained to use Gnome, which is just as well, since I run Awesome launched by "startx".

weland11년 전

> For example, another one would be connecting to a VPN, a task that NetworkManager greatly simplifies, assuming that such integration is available of course (e.g. if you think connecting to a Wifi network is problematic, try connecting to a L2TP over IPSec VPN).

That's because there is equally no uniform and simple way to connect to use those, either. The problem is that the "simplification" that NetworkManager provides is illusory. Yes, it provides an interface that is easier to access, and all the complexity is moved in the back, where it's handled by NetworkManager.

Unfortunately, the mechanisms through which it does that are fiercely complicated, too. I've had NetworkManager break on me countless times (I worked for a company that developed networking equipment for a while, so I've interacted with NM a lot), for a lot of silly things -- making me end up with slightly incorrect configurations or reapplying settings at weird times for no apparent reasons.

The end result is anything but simplified: not only do I have to deal with the inherent complexity of a quirky VPN connection -- now I also have to understand how NetworkManager reasons about it and figure out where it's wrong.

I also think it's misguided to have a single tool handle things so disparate like VPN and WiFi. It's not like you're ever going to be able to expose those through a unified interface -- NetworkManager's own D-Bus-based API being a prime example of that.

> There's also the issue that the simplicity exposed in your example is a little misleading. Will the system persist that command and re-execute it on boot? Will it remember my previously used Wifi networks and connect automatically should I want that? How can I view the available Wifi networks in range? Being able to connect to a Wifi network using a simple ifconfig command is great, but the notion that your 80% of use-cases is the same as everybody else's 80% is misguided at best.

You scan for networks with ifconfig <interface> scan.

The system will not persist commands (arguably, a good decision) but persisting those settings is pretty easy -- you just add the same parameters you pass to ifconfig in /etc/hostname.<interface name>. (The same parameters as in argv[1:n]).

The only thing it won't do out of the box is automatically connect to previously used wifi networks. I suspect none of the OpenBSD developers want that. I only needed a feature like that once, a few months ago when I moved to a new apartment and had no Internet connection of my own (cable company is shit) so I had to snoop from the free wireless of nearby cafes. The fact that the interface to ifconfig is so simple and uniform meant that the whole thing was a ten-line shell script to scan for, and connect to previously known networks, and a shell alias to save the current network to the list of known networks.

There's an even easier way, using virtual networks, but I didn't know about it at the time.

> So you're saying that xBSD is simpler / better, yet you can't use it on your laptop, as it lacks things you need. Well, no shit.

I have a Windows laptop, which I also had when I ran Linux. My day-to-day laptop runs OpenBSD.

xorcist11년 전

Network Manager still has problems. I've had a lucky streak for a few years where it hasn't given me problems, but the other day the GUI decided not to save my settings anymore. It looks like it does, but it doesn't. If I kill the beast and tap in the commands it just works, but if I run the daemon it keeps feeding the backends with old settings.

How do I debug this? There's just sockets and layers of GTK. I'll probably end up doing whatever voodoo I need to keep it away and give it another few years.

weland11년 전

dbus-monitor ( http://dbus.freedesktop.org/doc/dbus-monitor.1.html ) and a lot of patience are your friends. I know of no other method.

fragmede11년 전

In case you're actually interested in fixing that particular problem, it's probably polkit that's gone bad. To examine the issue further, nm-connection-editor is a separate binary that you can run from the command line, and it'll print errors on stdout - including what it's unable to do.

bad_user11년 전

Thanks for your detailed response.

So what laptop do you use for OpenBSD? I'm running Ubuntu on my main laptop and I tend to search for hardware that's known to work with it.

yellowapple11년 전

I'm not the parent commenter, but I personally run OpenBSD on a pretty wide variety of hardware, most recently (among laptops, that is) a PowerBook G4 and a Dell Latitude D830. Most things work out-of-the-box, but there are a few exceptions:

* Power management is nonexistent on PowerPC hardware, so I currently have to shut down my PowerBook between uses, since I can't put it in standby. This is annoying, but workable.

* Hibernation is buggy on the Latitude. Suspend works fine, though.

* Both the PowerBook and the Latitude required the use of fw_update to install nonfree firmware (for the Broadcom-based Airport wireless NIC and the Intel PRO Wireless 3495abg-or-whatever wireless NIC, respectively). Also slightly inconvenient, but - again - still workable.

* Some things don't really work on PowerPC, most notably Firewire. A slight bummer, but hopefully this will be resolved someday.

From what I understand, IBM/Lenovo ThinkPads are - just like they are with GNU/Linux - among the best laptops to use with OpenBSD; IIRC, a lot of the OpenBSD devs dogfood pretty heavily on them, so they get a bit more attention. I'd avoid anything with Nvidia graphics, whereas AMD/ATI or Intel graphics should be decent.

weland11년 전

It's an HP 4720s. I didn't buy it on purpose -- it used to be my girlfriend's. When it broke, I gave her my (much tinier) ThinkPad and after I fixed it, we never swapped them back.

I think the only thing that doesn't work out of the box is the weird WiFi adapter that has problems even on Windows. I just use a tiny USB adapter.

I also have OpenBSD installed on my even older laptop, which is an iBook G3. Power management and wifi don't work there but it is 15 year-old hardware, I don't really care.

stsp11년 전

> The only thing it won't do out of the box is automatically connect to previously used wifi networks. I suspect none of the OpenBSD developers want that.

That's not true. OpenBSD developers want this. There are several ideas floating around about making the kernel cache wifi passwords, scan and re-connect automatically when it lost link to the AP. This topic keeps coming up during hackathons.

For various reasons it's not as easy to do as one might expect.

The net80211 layer and wifi device drivers don't keep track of link state to the AP at present. This would need to be implemented first. It is essentially client-side roaming support. One way of doing this is to count missed beacons and assume the AP is out of range if no beacons have been seen for a while. Some devices provide such counters in hardware, some don't. The biggest part of the challenge is to make this work seamlessly with _every_ driver.

Then there's a risk of feature bloat. Add too much automation and you end up with something opaque like network manager which just pisses many people off. Add too little automation and you don't cover many use cases. And networking is not just about wifi, it's at least about ethernet and VPN as well. Some tools already exist to handle aspects of this (e.g. ifstated(8), trunk(4), interface priorities managed with ifconfig(8), a ton of ipsec tooling), and should be properly integrated in the design.

Another question is how to integrate with desktop wireless tools that come from Linux (e.g. wifi network pop-up menus for KDE4 and Gnome3) which usually require a backend using Linux-specific ioctls or dbus/NetworkManager/systemd APIs to function. But seamless integration with desktops would be outright awesome and make the system much easier to use for non-technical users.

There's probably a couple of gsoc projects worth of work in this. If someone is seriously interested ("no talk without diffs attached" kind of serious) in pursuing this I might be available to act as a mentor.

weland11년 전

I hope my reply didn't come pff as a passive-aggressive "those bastards don't care" or anything like that -- I didn't remember seeing anything about this on the mailing lists, so I just figured out no one wants it. I, for one, can't say I do, for several reasons -- ranging from "I'm a control freak so nothing connects automatically to anything on any computer I own" to "I know of no clean way to implement something like this so maybe we should learn to live without it".

Since it's not something I'm interested in, I probably just forgot that I read about it :).

icebraining11년 전

  $ vim /etc/network/interfaces

  auto wlan0
  iface wlan0 inet dhcp
        wpa-ssid <myssid>
        wpa-psk <passphrase hash>

You can also have multiple virtual interfaces configured in the same file as above, and then just do "ifup wlan0=virtualif" to switch.

Much ado about nothing.

joosters11년 전

Absolutely. It's also more secure this way, since you aren't putting the passphrase in a readable-by-any-user command line argument.

hhw11년 전

FYI, it's trivial to hide processes from other users on BSD with a sysctl variable.

icebraining11년 전

I think that's just in FreeBSD, not in others like OpenBSD.

Linux has copied that feature a few years ago, called it "hidepid".

curlypaul92411년 전

> The way OpenBSD handles WiFi configuration is a good example of this. Want to connect to a wifi network? ifconfig <interface> <ESSID> <passphrase>. If you need some other fancy flags for those 0.1% of hotspots in the world, you can do those, too (also through ifconfig) but it's that simple.

Hmm, I'm surprised OpenBSD supports this, since it will cause the passphrase to get stored in your shell history in plaintext.

yellowapple11년 전

I generally run it from a script that then prompts for the passphrase. I'm working on a little tool of my own to work as kind of a minimalist OpenBSD-specific network manager that'll store a list of encrypted passphrases and let me connect to a network without having to enter the passphrase and SSID each time.

peatmoss11년 전

This has long been my experience with BSD (back before jumping to OSX for some years, and now back to OpenBSD). There is a willingness to update core pieces of functionality where needed to reduce inessential redundancy.

Another example: console / keyboard config. In OpenBSD, I set this up through wscons. If set here, my keyboard settings get propagated in a robust, non duplicative way to X11. Contrast this with Linux, where you need to set up your keyboard config in at least two places to have, say, Dvorak in X11 and the console.

It's a minor thing, and one that Linux distros "solve" during installation by setting up the relevant configs. But it's more elegant in OpenBSD. Maybe that's because OpenBSD writes documentation that answers questions like, "How do a change my keyboard layout?" In OpenBSD, it's a simple answer. If the situation were the same as Linux, the answer would be longer. Maybe seeing that inessential redundancy in print is what spurs the project to action.

the_why_of_y11년 전

This is indeed annoying; fortunately David Herrmann is working on a new user-space terminal emulator for Linux called KMSCON which uses the same keyboard input code as XOrg (libxkbcommon) so there is hope for improvement.

https://dvdhrm.wordpress.com/2012/12/10/kmscon-introduction/

JdeBP11년 전

"is", "new", and "KMSCON" are all erroneous there. (-:

the_why_of_y11년 전

Ok, looking at the recent activity (or the lack thereof) in the github repo lets me be somewhat less enthused... but what's your objection to "KMSCON"?

JdeBP11년 전

And "your" and "objection" are erroneous, there. (-: Hint: ce7b9f50c3fadbad22feeb28e4429ad9bee02bcc

the_why_of_y11년 전

:-) Thanks, I totally missed that.

agumonkey11년 전

Seriously, we need Prolog infused user interfaces and components. Logic assistant to compose subsystem. Most user facing things are crippled (good thing sometimes) views on it, fuzzy matching, completions etc etc

Hello7111년 전

actually, wpa_supplicant isn't that hard to configure as long as you only use the GUI. just scan for APs, double-click on the network, and type in the PSK. no documentation-reading required.

weland11년 전

But I don't want to (just) use it through a GUI, I want to be able to script it. What am I, a connection-making machine :)?

aaronem11년 전

> wpa_supplicant isn't that hard to configure as long as you only use the GUI

Oh, my mistake! I thought I was using a Unix.

yellowapple11년 전

I use wpa_supplicant directly on my desktop (running Slackware64 14.1) and have no problem doing so via the command-line and conf file editing alone, though in my case it required adding a snippet to /etc/rc.d/rc.local to get it to connect to my wireless network on boot.

anon3_11년 전

What are some things on OpenBSD that don't work for you?

What sort of hardware are you running?

What about Adobe Flash on OpenBSD?

weland11년 전

> What are some things on OpenBSD that don't work for you?

The sort of things that you mentioned -- Skype, Dropbox. I also can't use OpenBSD for PCB layout (Eagle doesn't run on it; don't know about Kicad, but I have very little experience with it), but I don't really mind, because I have access to a licensed installation of Altium at work.

> What sort of hardware are you running?

Nothing special. It's a fairly high horsepower i7 box with 16 GB of RAM. The only component that didn't play nice with OpenBSD was the nVidia graphics card. I just bought a reasonable ATI card and it works fine.

> What about Adobe Flash on OpenBSD?

I haven't used the browser plugin ever since youtube-dl came out, not even on systems where it's well-(ish)-supported. But if you need it in the browser, I think you're pretty much out of luck.

ank_the_elder11년 전

I've used the crux linux distro (https://crux.nu) because it has a similar, BSD-like package manager, it's very clean and has a great community.

weland11년 전

I've been playing around with Void Linux recently (http://www.voidlinux.eu/). Unfortunately, even there, it's hard to escape a lot of the baroque nonsense of the Linux userland, and I eventually caved in.

mavhc11년 전

I used FreeBSD for a while because it had ZFS, and found Ports confusing and fragile. Maybe I was doing it wrong, but the handbook wasn't much use: "here's 4 different ways to do it, we're not saying which is a good idea". Every upgrade took ages, required reading a load of documents, and broke something.

There didn't seem to be an equivalent of Debian's Stable, everything was apparently the latest release.

protomyth11년 전

I have OpenBSD, FreeBSD, and Red Hat 6 (government wanted some software run and guess who gets the $) running in my server room.

Red Hat seems to be fine with yum, and I haven't had a problem yet. FreeBSD's pkg (pkg-ng technically) is ok, but I keep running into problems on upgrading because someone split a pkg or renamed it. I search but don't find a simple solution. I haven't had any problem on the OpenBSD side, but that could be because every 6 months do an upgrade with the new release. Patches are a bit harder on OpenBSD unless freebsd-update does something weird. the whole src thing in the freebsd-update bit me.

justwannasing11년 전

That's what the mailing list and the forum is for where you'd most likely told to just use 'portmaster' which is the easiest. Not that the others aren't easy, too, but it keeps tabs on dependencies for you but its best to pick one method and stick to it.

egwynn11년 전

I also was frustrated with how poorly the handbook explained ports/packages. But now that I understand how they work, I feel like it’s an elegant system that works well. I just wish it didn’t take so much trial and error to figure it out.

justwannasing11년 전

To be fair, chromium crashing is due to the increased complexity of chromium and nothing to do with FreeBSD as the maintainers have noted in their comments. They have found it increasingly difficult over the past couple of years to keep up with it though more manpower would help I'm sure. But such issues are fixed within a couple of weeks or days. the issue you speak of has to do with javascript in GMail and settings and how chromium interacts with that; not chromium directly.

I don't have the issue with Firefox, and never had any issue using the latest hardware, and I don't think the lack of Skype is FreeBSD's fault either but I forget.

ChuckMcM11년 전

Steven, if you're reading, you got your history slightly wrong. System V got its init handling from Sun's SunOS 4.x. It was negotiated as part of the integration between SunOS and System V which would become the "one UNIX for everyone". Unfortunately for all of us, AT&T really really loved "run levels" and Sun really really liked BSD's way of configuring the system. Which got you the unholy love child you saw in Solaris 2.0 and System V release 2.0.

For the other Sun folks from the systems group who quit rather than submit to the demands, you were right, I was wrong. We couldn't convince them of the error of their ways.

StevenJM11년 전

Thanks for the info. I've updated that section of the article with a note (and a link to this thread).

yuhong11년 전

This history looks wrong. Eg it was SVR4 that merged SunOS

ChuckMcM11년 전

You are correct it was System V, release 4 that merged with SunOS. It was also the release that Sun and AT&T "combined" the BSD init/rc system with the System V init/run-level system.

[deleted]11년 전

jveld11년 전

It got the job done by making the 99% majority of use cases more difficult in order to make the 1% minority simpler. This is a design pattern I think is being repeated in systemd.

I kinda had the opposite impression. I first encountered systemd when I started messing around with arch for a couple little vps projects. At the time I was doing sysadmin that involved both Ubuntu and CentOS, and I definitely found day-to-day tasks easier with systemd (better built in monitoring, consistent syntax, etc). For simple cases, writing a unit file sucks a lot less than writing an initscript. The warts in systemd only started to irritate me when I was first setting up my personal machines (one laptop, one tower) to run arch [1]. Even then, the bloat in the design irked me more than actually using it. So, I'm in favor of systemd, but not thrilled (dbus everywhere is annoying).

Then again, I don't maintain any packages with strange and/or complex daemons. If anybody's had a really hard time getting their stuff to work with systemd, I'd be interested to hear stories.

1: Not completely true. I want my damn log files back.

thaumaturgy11년 전

This is why I suspect that most of the divisions in the sysadmin community regarding systemd are generational. For people (like me!) who have been writing init scripts forever and can do it in their sleep, they'd prefer the flexibility and familiarity of init scripts to a new system that at first glance appears more limited.

For people who are less experien^H^H^H^H^H^H^H^Hcrusty :-), init scripts look like a horrifying way to manage a startup process, and just about anything -- including Yet Another Config File Format -- looks preferable.

I think this is also why so little progress is being made on resolving conflicts over systemd. There really isn't a whole lot of room for compromise; one group simply wants things to stay more or less the same (or evolve incrementally), the other group simply wants to throw it all out and start over.

I bet there would've been a lot less argument and vitriol about systemd if Debian hadn't made the decision to default to it, basically leaving all the crusty sysadmins homeless. Once Debian switched, there was a near guarantee that all of Linux was going to move to systemd. That suits one group just fine, another one not so much.

On the plus side, the BSDs should be seeing a really nice upswell of installations over the next couple of years, which is great, because they've been quietly building some pretty great operating systems that deserve more love.

chousuke11년 전

It's perfectly possible to run scripts with systemd unit files, so there's no real "flexibility" lost anywhere. The primary improvement is that systemd handles by default most of what used to be boiler-plate in every script, on top of calculating dependencies automatically. Then you get integrated process supervisor capabilities so that the init system actually knows whether services are running or not.

Speed was certainly a major motivator as well, considering the increasing popularity of containers and on-demand virtual machines.

To me it seems that "gradual evolution" was exactly what they did, and it wasn't really going anywhere. Lennart came up with systemd and convinced enough people that it's worth the pain of migration to get a clean start.

VLM11년 전

The key is the expense vs reward ratio.

I don't know how to write sysvinit scripts any more than I know how to write fizzbuzz. What I do know is how to program and specifically how to write and maintain and debug shell scripts. I NEED that for other automation purposes and cannot get rid of that mandatory requirement so it used to dovetail quite well with init scripts. There are corner cases and security issues and tradition, which means copying a known good init script and editing nothing but the executable names is a great start, but its not really a serious problem. I don't care if its verbose, as long as its simple and understandable and most importantly, predictable.

Now instead of applying a language and tradition I know to a simple task like init, I get to learn a whole new ecosystem and technology to do about the same thing I always did except vastly more complicated, and I can't even shed the old knowledge because its needed elsewhere. That makes overall systems harder to use, slower, buggier, and less reliable. And thats defined as "progress" because its new so it must be better.

chousuke11년 전

Honestly, I don't think that argument holds much water.

Init systems are not "just shell". If you go and try to write a sysv init script with only shell skills, chances are your init script will be broken in some obscure way. Perhaps because you didn't specify LSB headers correctly, or your PID file handling is subtly broken, or you're missing a check somewhere and the script is racey. I can't really say how much reading it would take to catch all the corner cases with sysv init scripts, but for simple cases, you will be able to write a correct unit file after about 15 minutes of reading the manuals.

Knowing shell helps, but you'll still need the tool-specific knowledge.