| |||||||||||||
Crowding out OpenBSDCrowding out OpenBSDPosted Nov 13, 2012 23:30 UTC (Tue) by rleigh (subscriber, #14622)Parent article: Crowding out OpenBSD
Though I doubt my opinion will make any difference, I dearly wish that projects such as systemd and gnome would appreciate that their use of Linux-only features is indirectly harmful in a multitude of ways to the free software ecosystem as a whole. Or rather, forcing the use of Linux-only features, and deliberately excluding others, since it's perfectly possible to use platform-specific features while also remaining portable. It just requires a good attitude and a little effort. Unfortunately these seem to be missing entirely in certain quarters in recent years.
(Log in to post comments)
Crowding out OpenBSD Posted Nov 13, 2012 23:41 UTC (Tue) by vonbrand (subscriber, #4458) [Link] Sorry, but the effort to run, e.g. systemd, over a non-Linux system is definitely not "a little." Writing portable code is very hard. Keeping it portable is a lot of of extra work, requiring many able bodies.
Crowding out OpenBSD Posted Nov 14, 2012 1:16 UTC (Wed) by mikemol (subscriber, #83507) [Link]
Are there decent 'lint' or 'valgrind'-style tools for warning about use of nonportable APIs (or APIs without universal behavior)? I could imagine such a thing being immensely useful for those of us who write software and care.
A 'lint'-style tool would obviously be a static analysis thing. A 'valgrind'-style might be able to spot uses of various calls without POSIXLY_CORRECT defined.
Of course, not all warnings are meaningful for a program. Not all platform targets are meaningful for a program. It'd be a matter of defining the testing scope, as with anything else.
Crowding out OpenBSD Posted Nov 14, 2012 1:34 UTC (Wed) by mpiechotka (subscriber, #83514) [Link]
The problem is not in tools or lack of them. Usually it is that you need to write different code to support different APIs. Think kqueue vs. epool vs. ... - they all sort of solve the same problem but might have different edge cases etc. And this is relatively easy part - if you try to manage the USB driver you need to talk directly to OS. In the end you have a massive code which can be inflexible because you haven't thought about multi-seat at the beginning and you need to add it now. Oh and you need to maintain so better prepare to have multiple VMs to test it on different setups.
As of testing - it might detect bugs but usually a) they are relatively simple bugs not big, large bugs like "you cannot do X on system Y" b) they test one code path and the bug might be in another (I'm not saying that testing is bad but that it is supportive to portable design not a full verification).
Crowding out OpenBSD Posted Nov 14, 2012 2:07 UTC (Wed) by mikemol (subscriber, #83507) [Link]
I wasn't looking for full verification, but rather tools to point at likely problems. Similar to how a compiler warns me that some code I wrote may not do what I intended...I'd love to have an API call audit warn me that I'm calling an API not present in all my supported platform targets. Or that I'm calling them with parameters that aren't properly supported.
I wish I had time to respond to all the things you mention. Some of them are going to be true of any software project (Paradigm shifts forcing architectural changes), some are greatly mitigated by avoiding unportable APIs unless there is a strong benefit to using them, and some are mitigated by keeping code modular and unportable portions behind abstractions. But I've got to go catch a bus...
Crowding out OpenBSD Posted Nov 14, 2012 8:17 UTC (Wed) by mpiechotka (subscriber, #83514) [Link]
No, they don't apply to all programs - I would say they don't apply to at least 99% of programs. There is no point in say graphical calculator to call any unportable API. However graphical calculator-like applications is not the only class of programs.
Modern DE usually at least try to manage devices, do power management, session management etc. - those are the hard problems. As of writing portable abstraction layer - it is usually good move if many components use it. However if you are the only user you moved a problem a bit, make architecture cleaner but haven't solve the ultimate problem - someone have to maintain the portable layer and move it forward on all platforms in sych. That means that say users are limited only to support of things that are on all platforms (and if say NetBSD have some wonderful feature the DE developed by NetBSD people couldn't use it).
I'm not saying that it is impossible but that it is hard (even if you do know something is not portable you don't necessary can solve it in simple way - I run at least once in problem when on system X you had do A while on system Y you mustn't do it). And given that by definition projects are understaffed I can imagine that portability might slip as a goal.
Crowding out OpenBSD Posted Nov 14, 2012 13:57 UTC (Wed) by mikemol (subscriber, #83507) [Link]
So we agree that for 99% of programs, the tool I'm asking for makes sense? I'm OK with that.
I disagree that you need to move the portability layer in sync. It makes pragmatic sense to have first-class and second-class platforms. First-class platforms can be in sync, second-class platforms can be a bit behind. As a user of a second-class platform[1], I understand this can be a pain, but I've also seen how it ultimately ends up work out.
At least with the portability layer, you've limited the number of lines of code that a porter needs to focus on.
[1] Gentoo. I'm sure the various BSD groups have it worse, but try running a pure-stable Gentoo. You pretty much can't. And there's no official stance on whether running a mixed stable/unstable setup is supported; ask two developers, you'll get three answers.
Crowding out OpenBSD Posted Nov 15, 2012 14:27 UTC (Thu) by khim (subscriber, #9252) [Link] So we agree that for 99% of programs, the tool I'm asking for makes sense? I think you both are mixing issues. My own experience is radically different: for 99% of programs full portability is a pipe dream (think getopt: pretty popular tool on *nix, but problematic if you need to support Windows, too - you either need to provide your own implementation bundled with your program or use some third-party package, etc). What is possible is to write, say, 90% of program in a fully-portable way, cover the remaining 10% with portability layer and keep 1% as a system-specific code surrounded by ifdefs. Sadly even if for typical program just 1-2% code must be system-specific these pieces impose insane amount of maintenance work - significantly more then 1-2%. And then the obvious answer is to use OpenSSH approach (born by OpenBSD, ironically enough): just cover your primary platform and don't think about portability. If someone wants to have portable version - they can do it as a patches on top of clean-yet-unportable code.
Crowding out OpenBSD Posted Nov 15, 2012 15:04 UTC (Thu) by mikemol (subscriber, #83507) [Link]
I wouldn't dream of "full portability". To me, that includes Linux, Windows, various BSDs, FreeDOS and places with 12-bit bytes. Even outside of practical considerations, to me "full portability" is a phrase that represents a paradox.
The way I see it, you have a tester program with a database of things to check against, and you give it an operational mode for the classes you care about. I.e. "warn me about anything you know of that's incompatible between Xorg and XFree86. Give me an error for anything that's incompatible between FreeBSD, OpenBSD and GNU." or "Give me an error for anything incompatible with unix-like systems [where that would mean common Linux environments, FreeBSD, OpenBSD, QNX...]"
I'm not suggesting the programmer should be demanded to provide support for all known platforms. I'm suggesting a programmer should be able to decide what platforms he'd like to support, get an advance rough idea at the parts of his program that are incompatible with that set, cull his supported platform set down to something manageable, and manage that.
The tool I'm describing would also be useful for people doing the active porting work, since it can immediately draw their attention to the places which need work.
Crowding out OpenBSD Posted Nov 17, 2012 22:15 UTC (Sat) by cmccabe (guest, #60281) [Link]
Someone should create a language that you can "write once, run anywhere." Radical to the max, dude!
That was a 90s reference, for you youngsters...
Crowding out OpenBSD Posted Nov 19, 2012 9:03 UTC (Mon) by ortalo (subscriber, #4654) [Link]
Hmmm, strictly speaking, it seems that this should even be a reference to the 70s and... C no?
BTW, note that C is the primary unifying factor between Linux and the BSDs in fact... and the main difference with the dominant proprietary OSes.
Crowding out OpenBSD Posted Nov 20, 2012 9:05 UTC (Tue) by cmccabe (guest, #60281) [Link]
One of Java's slogans was "write once, run everywhere."
I guess the implication was that C programs always required tweaking to run on platforms other than the ones they had been written on, and Java programs would not. Of course it didn't quite turn out that way in practice-- for example, Hadoop is mostly written in Java, and the process of porting it to Windows is still ongoing.
It's hard to find a free lunch in computing. Even harder to find a type of free lunch that someone else hasn't already spent years looking for.
Crowding out OpenBSD Posted Nov 20, 2012 11:52 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]
Uhm. I've been running Hadoop on Windows for _years_. The main stumbling block is setting up an SSH daemon, but even without it you can use Hadoop for certain limited tasks.
Crowding out OpenBSD Posted Nov 21, 2012 21:33 UTC (Wed) by cmccabe (guest, #60281) [Link]
Yes, there's a branch of hadoop called branch1-win that has been modified to work well on Windows. There's a JIRA tracking its progress here: https://issues.apache.org/jira/browse/HADOOP-8645.
Crowding out OpenBSD Posted Nov 20, 2012 12:11 UTC (Tue) by man_ls (subscriber, #15091) [Link] The idea was actually that a single "binary" (bytecode actually) could run, unmodified, on several platforms. Yes, "write" here is grossly misused.Given that the bytecode was in fact interpreted by the VM (and later compiled on the fly), the comparison to compiled languages was misdirected: Java had the inconvenience of having to compile and the slowness of interpreted languages, but none of the advantages. It would have been more appropriate to compare with interpreted languages such as Python or Perl, but then Java would have lost big time since VMs were only available for a handful of platforms and the competition can run, unmodified, on tens. Here by "platform" I mean a combination of OS and processor architecture. Nowadays Java is JITted and fast. But then again so is the humble javascript...
Crowding out OpenBSD Posted Nov 14, 2012 15:41 UTC (Wed) by cruff (subscriber, #7201) [Link] Writing portable code is very hard. Keeping it portable is a lot of of extra work, requiring many able bodies.I have to say that writing portable code is not really that hard, as long as you have a well defined common base, such as POSIX, to target. It just takes discipline and proper abstraction of the features you need that are not part of the base. I've written multithreaded C++ software for a variety of POSIX compliant OSes that only required some straight forward GNU make makefiles and a few OS dependent source files to fill in the missing or OS dependent parts. Didn't even need the mess of autoconf, etc. Once you stray far from the common base chasing the neat new features, whether for the wow factor or because of need, then it can be hard, but need not be complex if structured correctly.
Crowding out OpenBSD Posted Nov 14, 2012 18:28 UTC (Wed) by jwakely (subscriber, #60262) [Link]
> a well defined common base, such as POSIX
Which release? I'm not sure all the BSDs are down with some of POSIX-2008 yet (though I have only looked at recent-but-not-current releases)
> only required some straight forward GNU make makefiles
Later in the thread Espie complained [1] that GCC requires GNU make, apparently even that requirement is too much ;)
But then he also complained that GCC major releases are a few years apart (which was true a few years ago, but not now) and that changes only go in the trunk not release branches (so what? push your changes upstream and maintain patches in the ports collection against old releases, then drop the patches when a new release comes out that already has the changes ... surely that's obvious?) The implication in [1] that GCC only builds on Linux is ridiculous, plenty of other OSs manage to keep GCC trunk building without herculean effort, if OpenBSD can't it's not GCC's fault. I've made sure NetBSD does myself, not because I ever use it, but just because I had access to a box.
Crowding out OpenBSD Posted Nov 14, 2012 18:49 UTC (Wed) by jwakely (subscriber, #60262) [Link]
Sorry, wrong link, [1] should be http://article.gmane.org/gmane.os.openbsd.tech/30747
Crowding out OpenBSD Posted Nov 14, 2012 23:54 UTC (Wed) by wahern (subscriber, #37304) [Link]
It doesn't matter whether every Unix supports all of POSIX. What matters is that they everybody aims for common or similar abstractions, and that people test, test, test. "Portability" is a process.
I wrote a C library, wrapped in Lua, which does O(1) polling, async file notification, async DNS, async SSL, wrapped almost all of OpenSSL's X.509 key bindings, async descriptor passing, and async thread management in just about one week's worth of man power. The only dependency is OpenSSL.
Not only that, but I wrote it and maintain it for Linux, OS X, Solaris, FreeBSD, NetBSD, and OpenBSD.
http://25thandclement.com/~william/projects/cqueues.html
I learned one very important thing doing that: the BSDs generally have the better abstractions (particularly in kqueue), though Linux has more comprehensive POSIX API support. But in any event, it simply wasn't that difficult to write all of that portably, and in a small amount of code. And with VMs, it's been trivial to maintain the build for all the present releases of those systems.
The reason why people have a problem with portability is because even the best programmers fall into the habit of cargo cult programming. They're new to some API and scour usenet (or more likely these days, stackoverflow.com) looking for descriptions and usage examples. Then they copy the examples and move on.
But if you take the time to study the APIs, to study POSIX, and to study the implementation code (thank you, open source), then portability just isn't that big of deal. And the end result is that your program is more robust, because not only are more code paths tested, you actually understand what the heck is happening, as well as understand how and in what direction the APIs will evolve in the future.
It's important to constantly test on different platforms, though, and not to let portability issues fester and metastasize. But that's, sadly, what is happening with most open source software these days. People not only just don't care, they openly reject the idea portability. And that's a damn shame.
As for GNU Make, writing portable make is easy, but I allowed myself that single convenience, mostly because GNU Make is readily available everywhere. The BSD makes are almost as powerful, and I've even begun writing a make parser+compiler to translate between them. Mostly because GNU Make is darned ugly, and some of the BSD make syntax features are easier to understand while remaining just as powerful; so I want to write in a subset of of my favorite features from the different makes and then translate to each accordingly.
Crowding out OpenBSD Posted Nov 14, 2012 23:56 UTC (Wed) by wahern (subscriber, #37304) [Link]
And FWIW, signal notification. Although, Solaris doesn't have a pollable signal facility.
Crowding out OpenBSD Posted Nov 15, 2012 2:52 UTC (Thu) by nix (subscriber, #2304) [Link] Later in the thread Espie complained [1] that GCC requires GNU make, apparently even that requirement is too much ;)Well, that's politics, isn't it. GNU Make is GPLed, therefore bad (even though it doesn't contaminate projects built with it), therefore all projects should work with BSD make as well. (That the program being compiled is both GPLed and a flagship GNU project itself apparently does not affect this policy in its case, though common sense says it probably should.)
Crowding out OpenBSD Posted Nov 15, 2012 14:57 UTC (Thu) by jwakely (subscriber, #60262) [Link]
Indeed it is politics, and common sense should indeed let the GNU compiler use GNU make.
My point is that espie@ seems to want to have his cake and eat it. If you refuse to work with upstream (for technical or political reasons) then don't be surprised if upstream forgets about you.
On the plus side, as he says he is happy to leave kettenis@ to deal with GCC, and he recently pushed a load of patches from OpenBSD to GCC, which were gladly accepted (although I did forget to apply one until reminded, but I'd hardly call that "a fight".)
Crowding out OpenBSD Posted Nov 14, 2012 1:05 UTC (Wed) by josh (subscriber, #17465) [Link]
Have you looked at the list of Linux features that systemd requires? Have you ever read through that list and given serious consideration to how much work it would require to duplicate those features on another platform? I have, and doing even a fraction of it in a remotely acceptable and maintainable way would easily make for a full-time job. Do you happen to know a half-dozen OpenBSD developers with the time and inclination to do this work, continuously? If so, why shouldn't they work on the corresponding Linux-compatible kernel features instead, so that non-systemd programs can use them too?
I think this article highlighted the critical problem: Linux development has accelerated to the point that some other OSes don't have enough sparse developer time to keep up. Yelling "wait up" doesn't change that, it just slows Linux down so that other OSes have a better chance of keeping up with it.
I consider the BSDs a valuable part of the community, and I'd rather have multiple awesome OSes to work with rather than one awesome OS. However, I'd rather have one awesome OS than multiple less awesome OSes.
Crowding out OpenBSD Posted Nov 14, 2012 1:15 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]
picking on systemd for a moment (hopefully without spawning a 1000 post thread)
Part of the question, even on Linux is if systemd should really REQUIRE all those linux specific interfaces, or merely use them if they are available.
Even on Linux, sometimes people don't want to use cgroups and other things that systemd currently requires.
some of the problem that the BSD folks have is due to them just not having the manpower to keep up, but some of it is also due to some developers using new Linux features with no provision for running on a system without those features (be it Linux or *BSD)
Crowding out OpenBSD Posted Nov 14, 2012 1:41 UTC (Wed) by josh (subscriber, #17465) [Link]
When I said "given serious consideration to how much work it would require to duplicate those features on another platform", that allows for the possibility of providing the same features systemd does without using the platform features it currently requirs. Even allowing for that, I think my comment still stands: doing so would require a prohibitive amount of work.
You don't have to use cgroups; you do have to support the features systemd currently uses cgroups to support, such as supporting daemons that fork or double-fork or have child processes, while still respawning daemons that exit or crash. Upstart handles that "portably" by ptracing daemons that fork and capturing the relevant PIDs; that approach requires a great deal more code and work than using cgroups, because that approach doesn't rely on a platform feature specifically designed to support it.
Now repeat that exercise for the hundreds of systemd features supported by Linux platform features.
Crowding out OpenBSD Posted Nov 14, 2012 22:01 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]
> You don't have to use cgroups; you do have to support the features systemd currently uses cgroups to support, such as supporting daemons that fork or double-fork or have child processes, while still respawning daemons that exit or crash.
Why does the init system have to do this job?
If a daemon exits or crashes, is it really the right thing to just start a new copy? what damage did the failed instance do that may need to be cleaned up?
If a daemon has a complex set of dependancies (or deliberately does something like a double-fork to distance itself), is it really enough to only consider it 'failed' if they all exit? or should there be something more application aware (i.e. a daemon specific watchdog) that does this?
Crowding out OpenBSD Posted Nov 14, 2012 22:31 UTC (Wed) by raven667 (subscriber, #5198) [Link]
>> You don't have to use cgroups; you do have to support the features systemd currently uses cgroups to support, such as supporting daemons that fork or double-fork or have child processes, while still respawning daemons that exit or crash.
> Why does the init system have to do this job?
Its in the best position to do this as it's what starts the daemons and has a parent/child relationship with them. Process respawning is also available in SysV init as configured by /etc/inittab but that feature is incomplete.
> If a daemon exits or crashes, is it really the right thing to just start a new copy? what damage did the failed instance do that may need to be cleaned up?
I would think that in the general case the answer is very much YES. If you aren't worried about service outages I suppose you could make failure permanent, maybe wrap the daemon startup in a script which disables the service after the daemon exits. Seems kind of silly though.
> If a daemon has a complex set of dependancies (or deliberately does something like a double-fork to distance itself),
Double forking is more an implementation detail needed by other init systems, you don't need or want to double fork with systemd, although things will still work if you do.
> is it really enough to only consider it 'failed' if they all exit?
I'm not sure what happens if you challenge the init system in this way, what's the Right Thing(tm) to do in this case? If the processes maintain a parent/child relationship then you can rely on signals otherwise if the processes take input you can manage their sockets to detect failures.
> or should there be something more application aware (i.e. a daemon specific watchdog) that does this?
I suppose you could do that too, to handle cases where a process is wedged and needs to be restarted, but you solve 99% of the problem with just basic process monitoring using pretty standard techniques.
Crowding out OpenBSD Posted Nov 14, 2012 22:46 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]
> I suppose you could do that too, to handle cases where a process is wedged and needs to be restarted, but you solve 99% of the problem with just basic process monitoring using pretty standard techniques.
heh, I think people would argue that the sysV init solved 99% of the problem with even simpler tools.
I think that the simple case is handled well by SysV init, the really complex cases are not handled well by anything short of application specific watchdogs/monitoring/cleanup tools, so the question is if there is enough of a gap between these two to make the cgroups requirement (and overhead) worthwhile.
I've gotten to the point that everything I build is now either a cluster, or at least potentially part of a cluster, so I look at anything with the question in mind of 'how would I do this if it was part of a cluster', and this mindset really makes me question the value of trying to have the init system be more clever in addressing this problem.
One of the most common problems you run into when dealing with clusters isn't "the application exited or crashed", it's "The application is running, but wedged" I just don't see many cases where the cgroups approach to managing the app would have prevented problems (although, I freely admit that it has the 'cool' factor)
Crowding out OpenBSD Posted Nov 14, 2012 23:44 UTC (Wed) by bronson (subscriber, #4806) [Link]
For every cluster deployed, there must be hundreds or thousands of single hosts deployed to serve up wordpress or static content. Simple stuff written by a weekender, maybe with slashdot effects handled by CloudFlare. I think these guys would find systemd's respawning awesome. Much nicer than configuring and tracking down memory leaks in God, that's for sure! http://godrb.com/
Yes, clusters need more development effort and more powerful tools, but don't let that get in the way of the 80% solution.
Crowding out OpenBSD Posted Nov 15, 2012 1:13 UTC (Thu) by wahern (subscriber, #37304) [Link]
We've already had respawning with inetd. The fact that few used this almost universal facility should make one wonder whether it's really a feature developers don't enjoy reimplementing themselves.
That might seem illogical at first, until you consider how a developer's environment is setup. When developing a daemon you absolutely _hate_ centralized process management, because it tends to get in the way of debugging, among other things. Instead, you basically have to implement some sort of simple process management yourself, regardless of how your production environment will look. (If you're a web developer for a large website, imagine having to develop, debug, test using your process to upload and install in production... it'd be a nightmare.)
I usually start my development on OS X, and then port to Linux and the BSDs. Not once have I considered using launchd.
Crowding out OpenBSD Posted Nov 15, 2012 1:45 UTC (Thu) by josh (subscriber, #17465) [Link]
inetd tied process spawning to sockets. systemd doesn't; you can independently choose whether to use socket activation and whether to use respawning.
Crowding out OpenBSD Posted Nov 15, 2012 1:56 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
inetd tied process spawning to sockets, but there was also inittab for daemons that you wanted to have restarted if they exited or crashed.
Crowding out OpenBSD Posted Nov 15, 2012 3:33 UTC (Thu) by josh (subscriber, #17465) [Link]
True, and it seems quite unfortunate to me that distributions stopped using inittab for its intended purpose and started using it to launch scripts instead.
Crowding out OpenBSD Posted Nov 15, 2012 14:47 UTC (Thu) by khim (subscriber, #9252) [Link] inittab worked as intended couple of decades ago. But when daemons started spawning processes left-and-right and started depend on other processes it become useless. You can view systemd group-using core as "inittab done right".
Crowding out OpenBSD Posted Nov 15, 2012 15:34 UTC (Thu) by raven667 (subscriber, #5198) [Link]
Exactly, I see systemd as a return to unix roots, features that init would have had it continued innovating instead of stagnating and standardizing, not some weird departure against the overall style of the system.
Crowding out OpenBSD Posted Nov 15, 2012 22:04 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
parts of systemd could be called implementing init properly, but other parts are far more questionable.
why does device enumeration belong as part of init (udev)?
why does logging belong as part of init (the journal)?
Crowding out OpenBSD Posted Nov 15, 2012 22:44 UTC (Thu) by raven667 (subscriber, #5198) [Link]
>why does device enumeration belong as part of init (udev)?
It isn't part of PID 1 but hardware initialization is a dependency for services being started. The service manager ends up needing to know about hardware state for dependency purposes and therefore shares a lot of infrastructure with udev which is why they are distributed together now.
> why does logging belong as part of init (the journal)?
This is also not part of PID 1 . Whether system logging should be tackled as part of the systemd project is debatable. It is still an optional component though and might solve some real problems.
Crowding out OpenBSD Posted Nov 15, 2012 22:50 UTC (Thu) by raven667 (subscriber, #5198) [Link]
I thought of one more thing as well, the init system is in a prime position for logging both because it is connected to the stdout/stderr of processes that it spawn, where they might dump data, and it has its own needs for logging but by definition is started before any userspace logging service could be running. So there are at least a couple of cases that a PID 1 and related tools should identify and solve.
Crowding out OpenBSD Posted Nov 15, 2012 14:45 UTC (Thu) by khim (subscriber, #9252) [Link] I've gotten to the point that everything I build is now either a cluster, or at least potentially part of a cluster, so I look at anything with the question in mind of 'how would I do this if it was part of a cluster', and this mindset really makes me question the value of trying to have the init system be more clever in addressing this problem. Funny that you are trying to use cluster-aware approach to oppose cgroups. You do remember that cgroups were invented by Google engineers to manage clusters, right? SystemD just applies the same logic to local system management. One of the most common problems you run into when dealing with clusters isn't "the application exited or crashed", it's "The application is running, but wedged" I just don't see many cases where the cgroups approach to managing the app would have prevented problems (although, I freely admit that it has the 'cool' factor) That's strange because I see tons of places where cgroups solve cluster-management problems. What happens with your cluster if some unimportant task start to eat memory or CPU endlessly? With cgroups answer is obvious: it's bound by cgroup's limit. What happens if some task must be killed and restarted because your node is overloaded? Cgroups make sure you can kill the task reliably. Sure, that means that your tasks must be written to be killable, but it makes sense for clusters anyway since failed PSU can do the same thing suddenly and without warning.
Crowding out OpenBSD Posted Nov 15, 2012 20:53 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
I didn't say that cgroups did not have a place or a reason to use them.
I just said that requiring cgroups to properly start and stop a process is using the wrong tool for the job.
Crowding out OpenBSD Posted Nov 15, 2012 16:34 UTC (Thu) by raven667 (subscriber, #5198) [Link]
I wouldn't call cgroups "cool" but I would say that it's a better solution than what's offered in /etc/init.d/functions and ancillary tools like /sbin/pidof. In fact I recently had an outage due to a SysV script that on restart managed to killall rsyslogd but then only start the one instance causing an outage for the other instance on the same host. That kind of unnecessary outage is depressingly easy to have, we can do better.
Crowding out OpenBSD Posted Nov 22, 2012 14:53 UTC (Thu) by TRauMa (guest, #16483) [Link]
> people would argue that the sysV init solved 99% of the problem
In 15+ years of using linux I never came across a sysv init based system that could reliably restart mysql under all typical production circumstances. Now mysql used (?) to be a close to worst case behaving deamon, but it was also very popular, so if no distributor could handle it correctly with the tools given (and the init scripts tended to be very, very long and complex and hard to debug), how can one argue that it's a 99% solution?
Crowding out OpenBSD Posted Nov 22, 2012 19:21 UTC (Thu) by hummassa (subscriber, #307) [Link]
does systemd (and upstart) actually solve this problem?
Crowding out OpenBSD Posted Nov 22, 2012 19:36 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]
Yep. SystemD can reliably track mysql's state and kill it. Mysql recovery should then take care of unclean shutdowns.
Crowding out OpenBSD Posted Nov 22, 2012 21:37 UTC (Thu) by paulj (subscriber, #341) [Link]
How does it reliably track mysqls state btw? What would define a bad state requiring restart?
IME just because a process is running doesn't mean it's actually in a good state. You need some kind of heartbeat protocol. Does systemd implement something like that?
Crowding out OpenBSD Posted Nov 22, 2012 22:45 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]
No, the common problem with mysql is that it doesn't terminate cleanly. Its shutdown scripts can hang for minutes and _still_ leave hanging processes behind. These hanging processes later interfere with the startup.
SystemD nicely solves this problem. Hooking it up with an external heartbeat monitor should also be quite easy.
Crowding out OpenBSD Posted Nov 22, 2012 23:25 UTC (Thu) by cortana (subscriber, #24596) [Link]
systemd can be configured to require that a service regularly notifies that it is still up, or else it'll be killed & restarted. See http://0pointer.de/blog/projects/watchdog.html for the details.
Crowding out OpenBSD Posted Nov 15, 2012 1:27 UTC (Thu) by josh (subscriber, #17465) [Link]
> Why does the init system have to do this job?
That tangent misses the original point. Given a piece of software (systemd) that implements quite a few features by using Linux-specific platform functionality, I hinted at the amount of additional work required to replace even one of those features with a slightly more portable alternative. Responding to that with "do you really need that feature" misses the point completely.
Crowding out OpenBSD Posted Nov 14, 2012 1:54 UTC (Wed) by Lennie (subscriber, #49641) [Link]
The creator of systemd specifically made the choice created an architecture leveraging the best parts of the Linux kernel. So the way the program works, depends on the Linux kernel.
It means that systemd should be a fairly small program when compared if it needed the right abstractions and the architecture would probably have been different too.
Wayland is probably the same, I'm sure the code base is very small in comparison to X. For example keyboard handling is mostly handled by the kernel I believe.
I was already wondering how long the Debian project could keep the kFreeBSD port alive. For now in Debian they will probably let the user choose to use systemd or some other init. Maybe systemd will eventually the default with the Linux kernel.
kFreeBSD had ZFS and PF, what other user visible ? Will btrfs fix the biggest feature ?
It used to be true that academia developed new TCP/IP extension on the FreeBSD kernel first, this isn't true anymore. This is now Linux too.
Crowding out OpenBSD Posted Nov 14, 2012 4:23 UTC (Wed) by abartlet (✭ supporter ✭, #3928) [Link]
It reminds me very much of OpenSSH, for which we are very much thankful to the OpenBSD project. It too has a focus on just the bare essentials required to run on one OS - OpenBSD in this case - and a 'portable edition' patch for other platforms.
In my own work keeping Samba portable, we have like most large projects, a portability API (libreplace), mostly trying to emulate the C APIs of other OS versions onto Linux APIs where possible. The Kerberos implementation that we work closely with for the AD DC also has libroken, another portability API, and we link against libbsd for strlcpy etc.
I've done a reasonable amount of work in this area recently, and it is certain the portability doesn't come for free. Indeed, we have two major build systems because (in part) we don't want to drop systems that don't have python!
that smell Posted Nov 14, 2012 5:17 UTC (Wed) by ncm (subscriber, #165) [Link] strlcpy? Please tell me you don't actually use that.
that smell Posted Nov 14, 2012 11:15 UTC (Wed) by abartlet (✭ supporter ✭, #3928) [Link]
We do use strlcpy. We moved from safe_strcpy() and the custom wrappers fstrcpy() and pstrcpy() (for fstrings of 256 and pstrings of 1024 bytes) to at least something others have seen before. Natrually, a function called safe_ wasn't really safe (just safe against memory overwrite), but the name made us feel better about it despite having the same issues as strlcpy().
As code is rewritten, most strings are dynamically allocated talloc buffers, but stragglers remain.
Crowding out OpenBSD Posted Nov 14, 2012 9:43 UTC (Wed) by intgr (subscriber, #39733) [Link]
> two major build systems because (in part) we don't want to drop systems that don't have python!
Huh, there are systems powerful enough to build Samba that don't run Python?
Crowding out OpenBSD Posted Nov 14, 2012 13:22 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]
Yes, old big-iron batshit-crazy OSes in locked rooms without Internet access. Apparantly, Volker Lendecke has to provide support for these kinds of customers.
Crowding out OpenBSD Posted Nov 15, 2012 2:53 UTC (Thu) by nix (subscriber, #2304) [Link] The creator of systemd specifically made the choice created an architecture leveraging the best parts of the Linux kernel.cgroups? Best parts? Only from the perspective that it provides a feature that you can't get any other way. Not from the perspective that it's a crawling horror, nor, indeed that it's considered any good by any of the kernel developers. :)
Crowding out OpenBSD Posted Nov 16, 2012 21:34 UTC (Fri) by Tet (subscriber, #5433) [Link] Not from the perspective that it's a crawling horror, nor, indeed that it's considered any good by any of the kernel developers. :)I've heard that claim many times. But I'm too far removed from what's going on in kernel space these days. So if they're as bad as people are claiming, what alternatives does the kernel provide that give the same functionality as cgroups?
Crowding out OpenBSD Posted Nov 18, 2012 15:39 UTC (Sun) by nix (subscriber, #2304) [Link]
None. That's why they get used, even if they *are* a crawling horror internally.
Crowding out OpenBSD Posted Nov 14, 2012 1:51 UTC (Wed) by clump (subscriber, #27801) [Link] Linux development has accelerated to the point that some other OSes don't have enough sparse developer time to keep up. Yelling "wait up" doesn't change that, it just slows Linux down so that other OSes have a better chance of keeping up with it.Well said. I report a lot of bugs in Linux, and I can certainly say that the ones I report for RHEL are looked at far more often than the ones I report for Fedora. It's certainly no conspiracy, it's a matter of resources. To your point, I think the larger issue is that Linux has taken the dominant free OS role. The article rightly points out that certain projects are less concerned with portability than others, though with the success of Linux it's going to be hard for others to keep up.
Crowding out OpenBSD Posted Nov 14, 2012 12:05 UTC (Wed) by mezcalero (subscriber, #45103) [Link]
rleigh, it's really not as easy as you think. Making the event loop portable to kqueue is complex, but doable, I can agree to that. -- But the trouble starts beyond that. The BSDs don't have anything like cgroups. There's no way to attach a name to a group of processes, in a hierarchal, secure way. And you cannot emulate this. (And no, don't say "BSD jail" now, because that is something very different). But this already is at the very core of systemd. It's how systemd tracks services. And then, a big part of systemd is to track device status, as they come and go. Device management is fundamentally different on all OSes, you get very very different semantics. On Linux we have the udev rules set, which is entirely lacking on other OSes. systemd integrates very closely with that.
Portability of the most basic building blocks of the OS userspace goes way beyond just replacing a few system calls, it massively changes the semantics you expose, the behaviour you can rely on, and even becomes visible in the APIs you export.
Really, you should try porting this stuff, and you will run against a series of walls, and you cannot climb over them, as you will notice. When you start porting, don't start with the easy ones, such as epoll(), start with the hard ones, that are actually at the core, start with cgroups, start with device management. And you will notice that portability of this code is not just a question of caring, it's a massive undertaking.
Crowding out OpenBSD Posted Nov 14, 2012 12:34 UTC (Wed) by clump (subscriber, #27801) [Link]
I suppose the relevant question to ask you is if anyone has come forward to help systemd get ported to different operating systems?
Crowding out OpenBSD Posted Dec 5, 2012 1:27 UTC (Wed) by trasz (guest, #45786) [Link]
Not really. The relevant question would be why would anyone want systemd ported to different operating systems.
Crowding out OpenBSD Posted Dec 18, 2012 13:17 UTC (Tue) by clump (subscriber, #27801) [Link] Not really. The relevant question would be why would anyone want systemd ported to different operating systems.Or the relevant question could be exactly what I asked. If you have to ask why, you didn't read the article or the thread.
Crowding out OpenBSD Posted Nov 14, 2012 16:56 UTC (Wed) by michaeljt (subscriber, #39183) [Link]
> There's no way to attach a name to a group of processes, in a hierarchal, secure way. And you cannot emulate this.
One could require that administrators should create private users for daemons if they wanted to be able to shoot them down reliably. Not saying you should have gone this way, just that it would be another way of handling it.
> Device management is fundamentally different on all OSes, you get very very different semantics.
Yes, that can be a lot of fun.
Am I right though in thinking that the interfaces through which processes higher up in the stack communicate with systemd are normal DBus ones on the whole? If so then portability issues caused by software on Linux depending on systemd (I mean GNOME panel-like software) could presumably also be solved by making native infrastructure on the target system present those interfaces too.
Crowding out OpenBSD Posted Nov 14, 2012 17:15 UTC (Wed) by Trelane (subscriber, #56877) [Link]
Perhaps also the comparison with now is shortsighted. Yes, it would take a lot of things to port systemd to a BSD. However, it's not like the features that were developed were developed all at once. The pieces on which systemd relies have been developed over time, and the BSD folks in some cases actively chose not to develop similar or compatible systems. In other cases, it was a more passive decision e.g. deciding to focus developer time in other places. Though of course hindsight is 20/20 and it's hard to predict what features the next cool new thing will rely on, so it is oftentimes also understandable.
But the main message is that the entirety of systemd is not just systemd itself, and the majority of things that make it distinctive and non-portable were developed for Linux and not developed on the BSDs over a large swath of time, not all at once.
It should be noted that similar problems would likely arise from trying to port it to aix, hpux, solaris, OSX, or HURD (I suspect you know a bit more about what that would entail than I ;). But the BSDs are not special in this regard either.
(Incidentally, why the complaint about Linux instead of e.g. OSX's proprietary systems? Why are there not outcries against a lack of e.g. Aqua for BSD? Though perhaps this has been raised and answered elsewhere and I've not seen it.)
Crowding out OpenBSD Posted Nov 14, 2012 18:44 UTC (Wed) by jwakely (subscriber, #60262) [Link]
> why the complaint about Linux instead of e.g. OSX's proprietary systems?
I thought the same thing. I wonder how many *BSD users and devs were lost to Mac OS X. The BSDs are benefiting from LLVM and Clang, but I don't know if the same is true of other tech Apple have built on top of a BSD kernel.
BSD developers' moves to Apple? Posted Nov 19, 2012 22:38 UTC (Mon) by dmarti (subscriber, #11625) [Link] Just what I was going to ask. (Someone asked me what happened to *BSD user group meetings, and I guessed that they're still going on, but they're in a conference room in Cupertino and nobody who goes is allowed to talk to you.)
Crowding out OpenBSD Posted Nov 15, 2012 0:55 UTC (Thu) by geofft (subscriber, #59789) [Link]
Silly question: has anyone tried adding cgroup support to a BSD kernel (instead of trying to make systemd not use cgroups)?
Crowding out OpenBSD Posted Dec 5, 2012 1:18 UTC (Wed) by trasz (guest, #45786) [Link]
There is no point in doing it. For simple purposes, you're better off with login classes. For complicated - with jails. There is point in adding third mechanism.
|
|||||||||||||