This sounds like a horrible place to work at. Reminds me of bad startup culture, where everyone is expected to do long hours and people who want to work healthily are just pushed out of the company.
I think that in this case the ‘company culture’ tipped to the wrong side of the scale. @Work we do overtime, and we ‘expect’ people to be available off hours sometimes. But not to the point that it might be detrimental to your performance evaluation.
In some cases (i.e. our case/what i experienced) doing overtime together will actually strengthen intra-team relations; not sure about whether this will still hold up when overtime is expected ALL THE TIME.
In my experience, shared overtime always strengthens team bonds. If there’s too much of it, it unites the team against their employer which is obviously a terrible outcome from the employer’s point of view.
I think the other problem with shared overtime is that it slightly biases the teambuilding toward younger members of the company who don’t (yet) have obligations to a spouse or children. A small ripple, perhaps, but one that hurts a segment of the industry that we already tend to marginalize.
It’s a hard scale to keep balanced. I have family obligations myself (+1 and 2 kids) and thus are less inclined to put in overtime at the office. Time spent at home is a whole different story ;-)
Luckily we have quite a few developers with a wife/husband and kid(s); which results in less angry-faces when you decide not to join in one evening.
@hao: Do you really think family-bound developers are marginalized? I never had that experience here in the Netherlands.
I don’t understand the systemd hate, it seems to all boil down to Poettering-as-a-person hate. My experience with it has been very positive and it is surely a huge step forward from SysV.
And ‘it is not UNIX style’ arguments are totally bogus, it’s important to have working software, not UNIX-style software.
a) it appears to be a design goal of systemd to make Gnome not work on FreeBSD. It was working before. The reasons to hate this are fairly obvious.
b) last time I installed Pottering software it broke my sound. Once bitten and all that.
Well the b) happened in 2008, and was largely caused by Ubuntu adopting brand new technology too fast. I don’t use GNOME nor FreeBSD so I can’t comment on a).
I’ve had to deal with PA on systems other than Ubuntu and long after 2008.
Candid question (no, really):
What is Systemd improving over SysV? What is the problem you think it is solving?
systemd (SystemD if you want to piss off proponents) init specifically offers a bunch of benefits over sysv init, most of which revolve around not writing bourne shell scripts to launch system daemons and providing a framework for managing said daemons (instead of being handled ad hoc with more shell scripts and management functionality built into the daemon itself). This is pretty strictly beneficial.
The biggest complaints people have are that systemd has started implementing things way beyond init, and tightly coupling them together into a practically monolithic blob of system management code. Many of the non-init components enforce extremely questionable design decisions, and they’re practically impossible to replace because the systemd developers are actively hostile to independent development.
But SysV was created because of the same reason against older bsd rc.d system. SysV allowed to automatize programmatically and using GUI tools the management of the start up system. Also, it allows to manually customize the generated scripts.It may even allow status or reload commands if needed or possible.
So, other than because somebody though it was a good idea for a weekend project… why systemd?
edit: ignore this, true but not germane.
But sysv init scripts aren’t required to be Bourne Shell, they are processes. I have made lots of init scripts in Lua and Python. There just needs to be a clean protocol to denote what you accept and what you produce.
They are still arbitrary scripts, that’s the main problem. systemd (or, I dunno, upstart) provides declarative syntax to define inits. It’s much easier to write and/or generate.
But providing a declarative syntax for init scripts is orthogonal to init system itself. One could simply have
# do this on start
# do this on status
I don’t really understand why an init system needs to be more than a couple hundred lines of Lua.