Why systemd? - <AUTHOR> http://blog.jorgenschaefer.de/2014/07/why-systemd.html <comment><USER2> I think part of systemd's problem, as much as Poettering et al will try to deny it, is that it is full of NIH. One of the things this post criticizes, and Poettering criticizes, is the BSD-inherited daemon() function. Being curious, I looked at the function's implementation, both in FreeBSD's implementation, and glibc's implementation. FreeBSD's implementation handles pretty much everything the daemon writer themself would want to -- it sets the signal handlers and masks appropriately, double forks, creates a session, sets PIDs unless you tell it not to, and changes to the root directory unless you tell it not to. Glibc's misses important steps, like the signal manipulations, tries too hard to create a typical null device, and otherwise completely misses the point.

The biggest problem I see with system is that the developers don't play well with others. Instead of working with various parties, like the glibc maintainers, to fix deficiencies elsewhere, they expect developers everywhere to drop what they're doing to redesign how their projects work, when they work just fine for the many, many other unix architectures out there. Too much of systemd is based on magical pixie dust, compatibility be damned, and not enough on actually making things better.

<comment><USER3> > double forks

That's actually not something you want. It turns out that makes process management unnecessarily hard. That said, the glibc implementation isn't terribly good either. The CW is not to use either.

> I think part of systemd's problem, as much as Poettering et al will try to > deny it, is that it is full of NIH.

The most exasperated criticism I see about systemd is its use of dbus for a communications infrastructure, because dbus is both a system bus and a desktop session bus, and everyone associates it with the latter. If they'd just done the NIH thing and rolled their own communications protocol (like various other parties), they'd be deflecting a lot of that criticism.

Honestly, the NIH syndrome seems at least as prevalent amongst systemd's critiques.

<comment><USER4> You need to double fork() in order to ensure that the daemon won't be the controlling owner of the tty once it calls setsid(); i.e. that it will be re- parented to init.

So personally as a sysadmin that occasionally runs daemons from the command line I much prefer a double fork(); I don't want the daemon to exit when I log out.

<comment><USER5> Both forking and double-forking are completely wrong behavior for supervised daemons run as part of any automated system. Forking makes sense for small systems which lack any automated supervision and where a human admin is responsible for all process starting and stopping, but it's a bug anywhere else. Modern Linux has various methods for working around this bug (like the method of assigning an alternate process for orphaned descendants to be reparented to, which systemd uses, AFAIK), but really any production-quality daemon should provide a non-forking way to start it.

<comment><USER4> You _have_ to fork, it's the only way to make a new process. Now exactly which process does the fork()ing is, somewhat, academic. Some might argue about the band aid approach of the requirements of parenting and process groups; but that would require leaving POSIX (and hence source compatibility) behind. Allowing any process to set their own parent, process group, or controlling terminal without very strong bounds is dangerous; kind of like having Erlang with mutability, it's possible but it breaks the model (and all the cuspyness that comes with it) and leads to bad juju.

Requiring init to spawn the final daemon process (and hence getting the pid from fork()) is a red herring, any process can get a list of its children and query their proc structure (modulo permissions, but most sane people run init as root).

init should be as small as possible to do _only_ what it is required to do; this is simple anti-fragility at work. The less code and state the better. Feel free to stick your process manager, dependency calculators, and helper daemons in other processes. init should be able to handle something as catastrophic as a SEGFAULT and just execve(/sbin/init) and just carry on (while logging locally and remotely of course).

<comment><USER3> > You have to fork, it's the only way to make a new process.

I think he was presuming you already have all the processes you need, and this is just about getting them architected right.

</comment></comment></comment></comment></comment></comment><comment><USER6> The reason people use UNIX-like systems is because they work reliably. In order to make a complex system work reliably, it needs to be easily fixed. In order to fix a system, a person needs to understand it as well as be able to make a change in it. And in order to understand a system, it helps very much if that system is straightforward and lucidly verbose.

I hope systemd will live or die on its merits; I fear that it will take over via politicking.

<comment><USER7> > In order to fix a system, a person needs to understand it as well as be able > to make a change in it.

So if I follow you, it would be easier to grok the whole system if all the code was in different places?

<comment><USER8> Opaque C code that sits in lots of spread binaries and some end-user documentation in man pages don't help you a lot if have to debug an issue. It's okay from a user perspective but with systemd (or other complex systems that rely on in this principle) you need to start reading c-code, start gdb, deal with dbus... if it's a toolbox of scripts a `grep -r <error>` is often the first step on the way to understand and learn something and fix the problem.

This is more difficult if you have a lot of abstractions and binaries lying around. You need to start reading (often nonexistent) documentation and abstract C-code...

It likely does not matter for 95% of users and I've rarely had to do something like this but you are losing some control as developer/sysadmin. For some it's important as their productivity and job depends on solving such issues fast, others will never have this problem...

I've never had a problem with systemd through. But if you have it's difficult to fix it on your own.

<comment><USER7> > Opaque C code that sits in 20 binaries and some man pages don't help you a > lot if have to debug an issue. It's okay from a user perspective but with > systemd (or other systems that rely on in this principle) you need to start > reading c-code, start gdb, deal with dbus... if it's a toolbox of scripts a > `grep -r <error>` is often the first step on the way to understand and learn > something and fix the problem.

What's opaque about Free and Open Source C code?

Some might argue (this guy included) that statically typed, statically analyzed C code will result in fewer people having to debug their system code than the equivalent code written in a particular variant of shell code.

<comment><USER8> > What's opaque about Free and Open Source C code?

Everything if you are sysadmin/developer trying to fix an issue. At first you need debugging symbols to pinpoint the problem, then you need to read the source.. it all takes time. E.g. you need to learn about dbus-monitor and dbus calls and need to grasp some internal concepts of systemd if something goes wrong. It takes time and patience you usally don't have or don't want to spend on such details. For comparison i.e. FreeBSD rc is only shell-scripts: [http://www.freebsd.org/cgi/man.cgi?rc(8)](http://www.freebsd.org/cgi/man.cgi?rc\(8\))

I don't want to say that one is better than the other but the latter is for most folks far easier to debug and modify than the first. However as I've said it only really matters for few people. But I can understand that they are not particularly happy about this new complexity. And bugs happen.

<comment><USER7> > I don't want to say that one is better than the other but the latter is for > most folks far easier to debug and modify than the first.

Generally bad form to make claims on behalf of "most folks" since you are in fact a single person. It's totally a valid argument if you say this on your own behalf.

And yes, bugs happen. But fixing the C code, is in my experience, much easier than tracking them down in `bash -x`. Especially when dealing with race conditions between services/triggers/device initialization.

<comment><USER8> Yes. Shell scripts are it's own unique kind of hell. I'm really speaking on my behalf here. I can read shell good enough to follow and debug issues in it. However digging into internals of systemd and its interactions with dbus and other binaries is opaque for me.

Maybe it's just a different perspective - as a developer systemd likely eases a lot of pains and makes otherwise problematic and error-prone problems easy but as an sysadmin that mostly deals with servers it feels sometimes like forced unnecessary complexity that can introduce difficult to debug issues.

<comment><USER9> As a sysadmin, I'll take systemd units over SysV init scripts any day. They tend to be shorter, more simple to read, and I don't have to worry about the race conditions or services not restarting correctly due to varying daemonization techniques.

<comment><USER8> Yes. I don't intended to argue about that. For that systemd is perfect and I like using it too. I mean such problems as a hanging boot in an lxc-container where I've once got only a (not a lot on google about that at this time) red error message that something went wrong. How to go from there? It's sure possible but it's a lot of work.

I don't say that's the norm and I don't say this happens often but if you build custom stuff and do "strange" things it's easier to know what's going on if you grasp the complete system. This is more difficult with systemd.

I believe it's a valid criticism and I realize 95% of users never need to care about this. However it's still a valid point if you build complex systems that are not "off the shelf".

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER10> We often criticise systemd for being too bloated, and making it hard to write a drop in replacement. I totally agree with this line of thought.

However, in my mind it has made several awesome things possible. My boot time got dramatically shorter when I adopted it thanks to parallelization. Besides, daemons have now simple and robust service definitions. Sys V had become a mess!

Lastly, lightweight containers are the real-deal for small development tasks (not for production!). Just one command: systemd-nspawn, and you're ready to go. Docker is currently a bit more complicated to set up.

Arguably, many features, including containers, should be moved out of systemd. Right now, more than a monolithic architecture, I think systemd is rather shipping too many things under the same project umbrella.

<comment><USER11> > Lastly, lightweight containers are the real-deal for small development tasks > (not for production!).

I've come across this sentiment a few times in the last month, but I haven't yet heard an explanation other than "VMs are battle-tested and containers might leak data to each other". Is there something more that I'm missing? Why aren't containers a good idea to use in production?

<comment><USER12> If we (fairly or unfairly) group Linux' LXC (eg: docker) and * bsd's jails, the main contrast with "proper" hypervisors (xen/kvm/vmware/bhyve(? That new thing in freebsd 10?) is (the possibility of) full resource accounting/limitation. Go ahead run you pi-digit-finder at "100%" cpu, pipe /dev/zero over an ssh pipe to /dev/null on some box and pipe it to a local file as well: no other vm or the host will notice. You only get 1mbs, x cycles of cpu and x mb of disk.

Secondly, assuming a bug in the kernel, one might assume root in a container can lead to root on the host. Bsd jails have been pretty solid for the last few years afaik - but hardware support for virtualization might still get more of both separation/safety _and_ speed. There have been som bad bugs in (as i recall) the io system in xen, leading to similar issues ... but again the last time i saw anything on that was years ago.

Ymmv - generally docker doesn't have "run untrusted code, safely, as root" as a design-goal (yet, afaik) (not entirely sure about lxc, née vserver -- the underlying technology) -- so don't expect it to do that. Isolation and security (esp. without sacrificing performance) is very hard to get right. Or so a long series of privilege escalation exploits across many different os' seem to indicate.

<comment><USER13> > lxc, née vserver

Just to be a little pedantic, LXC has definitly be inspired by pre-existing Vserver and OpenVZ. But it's a different implementation.

A lot of things that are viewed as innovations from Docker really already did exist in 2006~2007. Maybe a bit cruder but not that much. OpenVZ was very close to that. AUFS is the only real innovation as far as I know.

Anyway, Docker guys were smart enough to ride the cloud wave and hype the thing. I'm pretty sure Parallels missed the boat because they went the opencore way (OpenVZ/Virtuozzo).

</comment></comment></comment></comment><comment><USER14> Lots of people do not seem to understand the criticism of systemd.

systemd = init system + a whole lot of other things.

When people complain about systemd,they usually do not complain about what it does or how it does it in the init system part.That part is pretty solid as far as functionality is concerned.

When people complain about systemd,they usually complain about the "whole lot of other things" part.Lots of people have different complains and my biggest one is on udev.

udev is a core component in any modern linux system I see systemd absorbing it as nothing but a political move and a power grab.They could have left udev as an independent project and just create a dependency on it.

The "whole lot of other things part" will,by definition,make any other project that is just an init system seem very much deficient in functionality when compared to systemd.

<comment><USER15> This init process debate has brought out one of the worst elements of people in the FOSS community: treating some FOSS technology as an extension of their identity.

Let's keep some perspective here. We are literally just talking about an init system. There are many others you can use. systemd is not taking away your freedom in any meaningful sense of the word "freedom". Debates should be about the technical merits of system _not_ baseless accusations that they are making a power grab.

<comment><USER16> > systemd is not taking away your freedom in any meaningful sense of the word > "freedom"

Systemd has made it impossible for me to run an up-to-date Gnome on FreeBSD. That feels a lot like taking away my freedom.

<comment><USER17> There's legal freedom, and there's practical freedom. Sadly, the latter is seldom talked about.

You can be stuck in a maze, in a pit or under a tree trunk. You're legally free, since no law or copyright license is saying may not get out. Yet, you're stuck and if you can't get out, you're not free at all.

When it comes to software, it is the size, complexity and complicated interdependencies that make the maze. As the system grows, an individual's practical freedom erodes. For instance, I complain about the web a lot. Even with a browser's source code and a permissive free license, there's close to nothing I can change about it in practice. It would be far too much work for me to maintain millions of lines of code and remain compatible and interoperable with a huge, fast-changing stack of technology... and the more you diverge, the harder it becomes. It's an uphill battle, and at some point you have to give up if you're not the giant. So the four software freedoms are reduced to two (or less). In practice I don't have the freedom to do what I want.

I think the FSF's stance of reducing freedom to a merely ethical issue is alarming. How would Dr. Stallman have felt if he had gotten his printer driver with a free license but so much code and complexity and dependency that it would've been impossible for him and a small team of hackers to actually port it and make it run on his system?

Of course, systemd alone is not approaching that level of complexity. Except that it's not only systemd.. the trend seems to be that all aspects of a modern OS are getting larger and more complicated. A little here, a little there, it all adds up and becomes _a lot, everywhere._ It's a sad trend.

There was a time when you could've picked up a book that pretty much describes all of your system's hardware at a low enough level so that you could start writing your own bootloader and OS from scratch, with the knowledge that you can interface with all the logical hardware devices. And it didn't take hundreds of thousands of lines of code. Now the amount of accumulated cruft we depend on is so large that the idea of writing your own not-a-toy OS is laughable...

Standing on the shoulders of a giant is necessary and helpful, but when you have to do too much of it, it stifles innovation and encourages monocultures.

I don't have anything against systemd per se; it doesn't represent my ideals, doesn't bring me features I want, and so I don't want to use it. If Ubuntu and Debian want to use it, they're of course free to do so. However, I am concerned that with the notion that "systemd has won", its proponents are going to assume it to be everywhere and build future software with the attitude that it is okay to depend on it -- who cares about the people who would prefer not to use it, let them suffer for disagreeing with the king!

Before the systemd rage, sysvinit might have been "the winner" on Linux in the sense that it was most widely used and supported. But we didn't have this sort of polarizing "sysvinit has won, fuck everyone and everything else" notion. Other distros with other init systems have happily coexisted all along, and these other distros haven't had to constantly fight a growing dependency on one specific init system.

<comment><USER18> > How would Dr. Stallman have felt if he had gotten his printer driver with a > free license but so much code ... that it would've been impossible ... to > actually port it and make it run on his system?

While I am not an expert on legal language and how it can be used by lawyers, I believe RMS and the FSF at least attempt to address this in the GPL Version 2 (there is probably a similar requirement in the GPL Version 3, but it is more complicated so I'm not sure which requirement corresponds to this quote form v2):

"The source code for a work means the preferred form of the work for making modifications to it."

Code that is so large complex that it is not practical to understand or port wasn't written by a human. Such code is probably a template or macro expansion of the real source, and the "preferred form" would be the pre-expansion source.

This may not cover all ways of obfuscating the code, but "preferred form" _is_ trying to be as inclusive as possible.

<comment><USER17> > Code that is so large complex that it is not practical to understand or port > wasn't written by a human. Such code is probably a template or macro > expansion of the real source

Or it was written by thousands of people over twenty years.

GPL doesn't protect you from accumulated cruft, complexity and snarly design that makes it hard to understand let alone modify a system.

</comment></comment></comment></comment></comment></comment><comment><USER19> Am I the only one who's disgusted with this bloated, convoluted, dbus- dependent pile of crap? I mean, c'mon, binary log files? I'll pass, thanks. It replaces way more than it needed to.

I prefer the BSD-style philosophy, nice, simple rc.conf, used to run Arch till it got infected with this garbage too. It slowly progressed away from it's BSD-style roots. So recently, I just gave up and moved to FreeBSD. Not a single regret so far.

<comment><USER20> I think I'm mostly fine with journald (as a concept). At least I can explain reasoning for it to myself. A switch from non-structured to structured data provides a significant advantage, and indexes are useful. At least I had too many times grepping a multi-gigabyte log file. Sure, relatively modern (RFC5424) syslog protocol has structured data too, but in my experience most software had never bothered to use it. So, forcing a switch through introducing another protocol that has structured data baked-in isn't a too terrible idea.

My only issue with journald's binary log files is that they're of homebrewn custom format, that's not accessible by any standard means. Plain text files aren't directly readable by humans, too, but we have cat, less or alike tools to pass such data to terminal (sometimes an iconv is required, say, if log entries contain filenames that has characters outside of ASCII range), and those tools are available on every modern OS out there.

Personally, I think, a compromise that'd satisfy me (YMMV) would be either an industry-standard log format (like, maybe, sqlite - it's fairly simple, universal and omnipresent nowadays) or, even better, storing data in text files, but having accompanying binary index and metadata ones that store non- human-readable stuff (like hash chain - bet, no sane human would ever check cryptographic log integrity by hand) and provide additional information for faster machine access.

But the heck journald is a tightly-coupled part of into systemd instead of being a separate project is beyond me. I can't reject that systemd has some good things about it too, but it's too terribly monolithic and unhackable compared to mostly-scripted init systems. And such negative points easily outweigh the positive ones.

<comment><USER2> The biggest problem with dropping the syslog protocol altogether is that there's a huge amount of other stuff that speaks syslog. Things like networking gear use it for the same purposes as a normal *nix box, and getting them to switch is going to be like pulling teeth. With your particular case, I'd say you should look at rsyslog and/or syslog-ng. Both of them have backends that talk with actual databases, so you can have all your tools readily available, and can additionally dump to plain text and/or email messages at the same time. As to the why for journald, it seems very much like the rest of Poettering's MO of NIH. He doesn't seem too capable of working with other project makers to get his goals handled, so just does everything himself, to the detriment of the overall community.

<comment><USER20> Well, journald has syslog compatibility layer and can talk syslog, so supporting any existing software is not an issue. It doesn't speak syslog by itself, so it probably can't forward logs to another networked syslog server, but I don't see anything that prevents implementing this, if necessary.

The point is, journald also introduces a new protocol that's oriented at logging structured data. This way it not just provides a feature, but forces developers to think about structuring their log output in a machine-readable manner. I think that's the excuse that I believe is the journald's raison d'être and that I personally accept.

Just my opinion, though.

<comment> jude- Compatibility isn't the problem. The problem is the use of structured binary data _itself_ for logs. Logging binary structures instead of raw text makes it very difficult to recover from crashes or misbehavior, since the logging facility (journald or otherwise) must ensure that the log's structure on disk is consistent at all times.

I've seen more than my fair share of journald corrupting its own log due to unclean shutdowns. If I'm going to be grepping the journald log file anyway to reconstruct it (possible, but not easy, since journalctl is useless here), then why bother using it at all? It fails at the very task it was built for.

<comment><USER18> > journald corrupting its own log due to unclean shutdowns

Exactly! What the binary log advocates seem to be missing is that those unclean shutdowns (often called "crashes") are probably the very thing you are going to want to search for the in log. In general, few people care how (or if) log stores that the cron daemon yet again ran the hourly maintenance without any errors. What _everybody_ who has had to search a system log cares about is "what happened right before the crash happened".

The current data that needs to be committed to the log _successfully and immediately_ almost by definition happens at a time when you do not have the time for the complexity of an atomic addition to a database. Often there is barely have time to any disk write at all.

The only way make the system log useful would be to make adding events synchronous. As nobody wants to deal with a syslog that is 10,000x slower (or worse), the only sane option is what we always did - make the writes simple and immediate, and defer any fancier feature.

Have they never heard of "log parsers" before? If you want it in a search able DB (which can be very useful), you do that from original log either as an async daemon or defer it with cron or similar.

</comment></comment></comment></comment></comment></comment><comment><USER21> Disclaimer: I develop uselessd, probably have a warped mindset from being a Luddite who values transparency, and evil stuff like that.

The author of this piece makes the classic mistake of equating the init system as the process manager and process supervisor. These are, in fact, all separate stages. The init system runs as PID 1 and strictly speaking, the sole responsibility is to daemonize, reap its children, set the session and process group IDs, and optionally exec the process manager. The process manager then defines a basic framework for stopping, starting, restarting and checking status for services, at a minimum. The process supervisor then applies resource limits (or even has those as separate tools, like perp does with its runtools), process monitoring (whether through ptrace(2), cgroups, PID files, jails or whatnot), autorestart, inotify(7)/kqueue handlers, system load diagnostics and so forth. The shutdown stage is another separate part, often handled either in the initd or the process manager. Often, it just hooks to the argv[0] of standard tools like halt, reboot, poweroff, shutdown to execute killall routines, detach mount points, etc.

To stuff everything in the init system, I'd argue, is bad design. One must delegate, whether to auxiliary daemons, shell scripts, configuration syntax (in turn read and processed by daemons) or what have you.

sysvinit is certainly inadequate. The inittab is cryptic and clunky, and runlevels are a needlessly restrictive concept to express what is essentially a named service group that can be isolated/overlayed.

Of course, to start services on socket connections, you either use (x)inetd, or you reimplement a subset or (partial or otherwise) superset of it. There's no way around this, it's choosing to handle more on your own rather than delegate. In systemd's case, they do this to support socket families like AF_NETLINK.

As for systemd being documented, I'd say it's quote mediocre. The manpages proved to be inconsistent and incomplete, and for anyone but an end user or a minimally invested sysadmin, of little use whatsoever. Quantity is nice, but the quality department is lacking.

sysvinit's baroque and arduous shell scripts are not the fault of using shell scripts as a service medium, but have to deal with sysvinit's aforementioned cruft (inittab and runlevels) and the historical lack of any standard modules. BSD init has the latter in the form of /etc/rc.subr, which implements essential functions like rc_cmd and wait_for_pids. Exact functions vary from BSD to BSD, but more often than not, BSD init services are even shorter than systemd services: averaging 3-4 lines of code.

A unified logging sink is nothing novel, it's just that systemd is the first of its kind that gained momentum, but with its own unique set of issues. syslogd and kmsg were still passable, and the former also seamlessly integrated itself with databases.

Once again, changing the execution environment is a separate stage and has multiple ways of being done. Init-agnostic tools that wrap around syscalls are probably my favorite, but YMMV.

As for containers, it's about time Linux caught up to Solaris and FreeBSD.

<comment><USER22> > The init system runs as PID 1 and strictly speaking, the sole responsibility > is to daemonize, reap its children, set the session and process group IDs, > and optionally exec the process manager.

The process manager gets killed. How do you recover?

If you have respawn logic for it in PID 1, how do you log information about a failure to respawn the process manager?

Perhaps you build in some basic logic for logging. Where do you _store_ the data? What if the user level syslog the user wants you to feed data to can't be brought up yet, because it depends on a file system that is not yet mounted?

There may very well be alternatives to the systemd design, but I've yet to see any that are remotely convincing, in that most of them fail to recognise substantial aspects of why systemd was designed the way it is, and just tear out stuff without proper consideration of the implications.

Most proposed alternative stacks to systemd falls down on the very first question above.

I agree with you that it doesn't seem like a great idea to stuff everything in the init system, but I don't agree that "one must delegate" unless the delegation reduces complexity, and I've not seen any convincing demonstrations that it does.

I'd love it if someone came up with something that provided the capabilities and guarantees that systemd does with indepenent, less coupled component, though.

But there's no way I'm giving up on the capabilities systemd are providing again.

<comment><USER23> Isn't that a pretty narrow corner case? I can count the number of times the process manager has been killed on one hand.

<comment><USER24> Also you depend every-day on another process that is special in some sense just as the process manager: Xorg. If Xorg dies all your desktop applications die. By your line of reasoning Xorg should be moved into PID 1 too, which is definetely not a good idea.

I don't say that Xorg hasn't crashed, it did rarely when running RC code or proprietary drivers. In fact I probably had as many Xorg crashes as kernel panics, which says something about how stable Xorg is. Still I wouldn't want to run it as PID1, where a crash would really bring down everything.

<comment><USER22> I don't understand how you come to the conclusion that putting Xorg in pid 1 would be even a remotely fitting comparison.

For starters, as an example, I have 100 times as many servers than I have desktops to deal with - for a lot of us Xorg is not an important factor. But the process manager is vital to all of them - server and desktop alike if you want to keep them running. If the process manager fails, it doesn't matter if it wasn't Xorg that took things down.

Secondly, that X clients fail if the server fails is not a good argument for moving Xorg into pid 1 too, because it would not solve anything. If pid 1 crashes, you're out of luck - the best case fallback is to try to trigger a reboot.

Having (at least minimal) process management in pid 1 on the other hand serves the specific purpose of always retaining the ability to respawn required services - including X if needed. (Note that it is certainly not _necessary_ to have as complicated respawn capabilities in pid 1 as Systemd does).

Having Xorg in pid 1 would not serve a comparable purpose at all: if it crashes, the process manager can respawn Xorg. If you then need to respawn X clients, and be able to recover from an Xorg crash, there are a number of ways to achieve that which can work fine as long as your process manager survives, including running the clients under a process manager, and have them interface with X via a solution like Xpra, or write an Xlib replacement to do state tracking in the client and allow for reconnects to the X server.

Desktop recoverability is also a lot less important for most people: Every one of our desktops have a human in front of it when it needs to be usable. Most of them are also rebooted regularly in "controlled" ways. Most applications running on them get restarted regularly. People see my usage as a bit weird when I keep my terminals and browsers open for a month or two at a time.

On the other hand, our servers are in separate data centres and need to be availably 24x7, and many have not been rebooted for years, and outside of Android and various embedded systems, this is where you find most Linux installs.

While we can remote reboot or power cycle most of them, with enough machines there is a substantial likelihood of complications if you reboot or _shudder_ power cycle (last time we lost power to a rack, we lost 8 drives when it was restarted. Even with "just" reboots there is a substantial chance of problems that requires manual intervention to get the server functional again (disk checks running into problems; human error the last time something was updated etc.)

That makes it a big deal to increase the odds of the machines being resilient against becoming totally non-responsive.

<comment><USER24> I think you raised an interesting point here 'for a lot of us Xorg is not an important factor', I agree. The same could be said about some of the features that systemd provides that cause a lot of flames (binary logs). It has been said before that systemd is monolithic, and this is probably what makes switching so hard.

It is all-or-nothing, whereas if you could gradually replace the old sysvinit/policykit/consolekit/etc. stuff with systemd/logind then problems during that transition could be debugged more easily. You could also choose to not replace some components where the systemd/non-systemd replacement is broken.

</comment></comment></comment></comment></comment></comment><comment><USER25> Case in point .. today .. rebuilding an X11 desktop system on Gentoo, some weird set of dependencies around gnome beneath the window manager wants to pull in systemd. I finally work out a way around it, but it wastes half an hour of my time.

My take: Containers are not well managed by general, daemon-oriented process supervisors with a localhost-oriented purview. However, those supervisors would do well to use container-related features to better secure and manage daemons as appropriate. In future, processes will be more likely managed across clusters by parallel capable supervisory systems with high availability goals and network infrastructure configuration, load and topology knowledge. Less and less people will even see the init system, except perhaps behind a logo or as it flashes past while booting their device in debug mode.

(Edit: stumbled on [http://www.gossamer- threads.com/lists/gentoo/user/284741](http://www.gossamer- threads.com/lists/gentoo/user/284741) which explains the scenario .. would hate to be on BSD)

</comment><comment><USER26> I think systemd actually clears up a loot of stuff. As the article describes.

The main thing that scares me is the binary loging format I can think of some benefits but mostly it just seams scary. I guess I will get go se later if the benifits outweighs the rest.

<comment><USER27> I was actually pretty happy with the way upstart handles logging... it's about as transparent, and easier to deal with.

</comment></comment><comment><USER28> I'm new on the boat about systemd debate so I'm still reading and reviewing the situation. But the more I read the more I'm getting away from systemd.

In principal everybody is on terms with the need for a new and modern init system. But yet I'm not even sold on this issue. sysvinit is still holding stance with extra tools and doing it's job cleanly. By introducing a fully reimplemented and still controversial system with many dependencies and with need for many reimplementation on our existing software we are not helping the issue but blurring the waters.

And What's the fascination about boot times?

Nowadays on desktops nobody boots. You just boot once and hibernate/suspend forever. And for servers, if you are rebooting you are doing something wrong. So pulling efforts from building controversial init systems to optimize hibernate/suspend in the kernel would be a better effort on this field.

<comment><USER29> boot times are the least important reason to use systemd.

</comment></comment><comment><USER30> There's a lot of negativity going on here...

As far as my experience goes, I've found it actually works really well on all the servers I've moved to CentOS 7 and on the Fedora desktop I play around with (my main dev machines are Macs) it's significantly improved boot time...

I'm sure there are some valid concerns about design and such, but as far as my usage in production goes, I can't say I've had a single problem with it... It makes it a lot easier when I need to write files then the messy init scripts before also.

</comment><comment><USER31> Out of confused mind.)

There is _no fundamental problem_ that it "solves" which other UNIXes presumably still does have. The problem does not exist. AIX, Solaris, *BSD and many old-school Linux guys will tell you that.

Also, any old-school guy will tell you that a kitchen-sink, put-it-all-in design is a wrong way.

btw, user processes supervision is a task of an OS kernel, which it handles via a bunch of specialized syscalls, not of some "man-in-the-middle" user- level daemons.

There is actually nothing to talk about, except some ambitions and bad designs.

<comment><USER32> _btw, user processes supervision is a task of an OS kernel, which it handles via a bunch of specialized syscalls, not of some "man-in-the-middle" user- level daemons._

I'm pretty sure /sbin/init runs in userspace even on *BSDs and Solaris, and does process supervision.

<comment><USER31> You would be surprised how a few processes it supervises. getties (remember these?) what else?

initscripts has nothing to do with /sbin/init, surprise?</comment></comment></comment>


Why 12-Foot Traffic Lanes Are Disastrous for Safety - <AUTHOR> http://www.citylab.com/design/2014/10/why-12-foot-traffic-lanes-are-disastrous-for-safety-and-must-be-replaced-now/381117/ <comment><USER3> I'm seeing a lot of resistance to the idea of narrower city streets on this thread. The advantages of narrower city streets (and hence, crossings) goes far beyond safety. It actually enhances quality of life in a significant way. A wide, four lane highway running across your town basically says humans must come encased inside an automobile. Pedestrians and cyclists become second class citizens. It's a design driven for the convenience of cars and to the detriment of humans.

Here's a far more engaging critique of car-first design by James Kunstler: [http://youtu.be/Q1ZeXnmDZMQ](http://youtu.be/Q1ZeXnmDZMQ)

<comment><USER4> The university I went to invested in skywalks to replace many if almost all cross walks within and on the edges of campus. It does require more energy to go up and down sometimes, but it means everyone is safer and everything still flows.

<comment><USER5> The big problem with skywalks is that they result in the streets underneath them being empty (of pedestrians). This has downsides:

      - Empty streets feel less safe
      - Stores get less foot traffic
      - Cars are more likely to speed when there's no one walking about

So they really can suck the life out of the street.

<comment><USER6> They also, y'know, cost a ton.

You're not going to put them at every crosswalk

<comment><USER7> I doubt they actually cost all that much relative to the cost of a 40+ story buildings.

</comment></comment></comment></comment></comment><comment><USER8> The standard of the average academic/research paper is low enough that very few stand on their own. This, of course, is the reason why certain media outlets are able to make lots of money with bi-weekly, likely untrue claims that _< insert thing here>_ "causes cancer".

This article repeats some conclusions from various research efforts of unknown (to me) quality, most of which carry caveats, and none of which were titled "Effects of Lane Width on Pedestrian Safety: A Quantitative View". These _weak_ (not pejorative, just opposed to _strong_ ) statements are then used as the base assumptions atop which a _logical_ argument is constructed - <USER2> argument that is incomplete. The relationship between speed and mortality is only attacked from the perspective of what happens once a collision has taken place, for instance, but there will likely also be a relationship between speed and the level of caution exercised by pedestrians, but no _evidence_ about this is presented.

This is a question in need of comprehensive study; the tidbits presented here are neither strong nor complete enough to say anything absolute, much less accuse anyone of having blood on their hands.

Personally, I think such a study would validate much of what the author feels. But it is only my gut that says that, I'd need a study to _" know"_. As such this comment is not meant as a criticism of the author or the thoughts in the article, but more as a sort-of defensive reminder of what the scientific method means.

<comment><USER9> Another thing missing: What is the economic cost of slowing everyone down? Clearly if people spend 50% longer commuting because they're driving 20mph instead of 30mph, that has real consequences for both their economic output and quality of life (commute time has a surprisingly large impact on a person's overall happiness!). The author disregards this factor entirely.

I've seen this pattern in a number of "unintuitive and seemingly clever" traffic engineering tricks proposed in recent years. For example, it has been shown that removing all traffic signs can in fact improve safety -- again by slowing everyone down.

Another similar point (mentioned in the article) is that expanding freeways doesn't reduce congestion, because the new lanes are filled quickly. The argument is, apparently, that we therefore should not bother expanding freeways. The argument ignores the fact that the expanded freeway is serving many more people, creating immense value even if the speed of traffic hasn't improved.

(For the trolls: I personally take the train rather than drive whenever possible.)

<comment><USER10> The problem with the expanded freeways is that they create traffic. People that previously used public transportation now take the car because it's just faster. Then other people take that job on the other side of the city, or buy the house further out in the suburbs because the new lanes makes driving faster (for a while).

Of course it is good for the economy that people can commute effectively. But by building more lanes we are choosing spread out cities dominated by highways where no one wants to live and instead drive to work from the suburbs.

And there are alternatives. We can choose more densely populated cities where the streets are dominated by pedestrians and people commute shorter distances mostly by public transport. Much better for the environment, and most importantly, better for people.

And we are making that choice whenever we chose between using the land for new roads or using the land for new pedestrian buildings and railways.

<comment><USER11> > Much better for the environment, and most importantly, better for people.

Please don't put out blanket claims like this and pretend they're _obviously_ true, and then use them as justification for your particular view of how society should structure its geography. Some people _hate_ densely populated areas. It would be utterly detrimental to my mental health to live in one. So if I have the choice to not live in an urban area, I'm going to take it.

I have a 45 minute commute each way every day to work. Long commutes _suck_. Living in the city sucks _way more_.

<comment><USER12> My friend who lives in the downtown area sent me a picture today. Someone busted out the elevator button to the top floor (where they live of course). In densely packed areas the ill behavior of just a few bad actors affects many more people. Having nice things close is great, though also having more bad thing close would take a toll on my mental health too.

</comment></comment></comment></comment></comment><comment><USER13> This article makes me genuinely angry for burying the explanation for why 12 foot traffic lanes are dangerous beneath many paragraphs of what the author clearly thought must have been clever banter, wasting my time. Note to authors: put the claim and the gist at the top, then defend it with more details. Don't burry the gist of the article with shitty and annoying writing, making the reader scan paragraph after paragraph of bullshit to establish if the article is worth reading in the first place. In this case, it wasn't.

<comment><USER14> Your anger should be directed to the person who linked to the site, and not to the author.

The information you want is available at [http://nacto.org/docs/usdg/lane_widths_on_safety_and_capacit...](http://nacto.org/docs/usdg/lane_widths_on_safety_and_capacity_petritsch.pdf) and in exactly the format that you want. Indeed, this is the source material for the article that you are angry about, as was cited in the text.

The author wrote the article for people who _want_ to read "shitty and annoying writing". There's enough of that writing in the world to know that those readers are in the majority. Those people also need convincing, don't they?

</comment></comment><comment><USER15> I see a huge number of comments on this thread implying that carefulness is related to the road danger. It's the perceived danger that matters. You don't need to make the roads more dangerous, just need to make them look so.

I'm not from USA, and on the last time I visited it, I noticed how recklessly people drive on the highways, most of them were on the phone, eating, or doing something else(there was even a lady fixing her hair with her right hand, talking on the cellphone with her left hand and holding the steering wheel with her elbow, that freaked me out).

If those people behave the same driving on a street, I can see that being the cause of the majority of accidents, since the reaction time for events will be smaller, since most occurrences happen within a few meters of the car.

Finally, I know that this is not the focus of the article, but the USA cities need to focus more on the people that either cannot or will not(like me) drive. LA, LV and Miami, for instance, were pretty hellish until I finally gave in and rented a car, with poor public transportation and pedestrian access.

<comment><USER16> I'm frequently surprised by the lack of sidewalks everywhere outside of the downtown core of many cities. Perhaps its different in cities I haven't been to, but compared to where I grew up in, it does seem like everywhere else is car-first. Its not just the states or even big cities, I've lived in a small town in Ontario that was similar.

It makes me wonder if its related to the age of the area. Newer areas seem to have more sidewalks.

<comment><USER17> I visited San Diego (I was living in the UK at the time, and found it impossible to get anywhere. I was routinely told that only poor people caught the bus (and it could be dangerous), and there were no pavements anywhere to walk on. I walked to the nearest burger place for lunch every day, a hellish 1-mile jaunt through rubbish-strewn wasteland getting beeped at every time I tried to cross a road.

In contrast, every European and Australian city I've lived in has catered for pedestrians and cyclists to the extent that it's at least possible to walk or bike anywhere you need to go (even if it would take hours in these huge Aussie cities).

I still wonder at it. How do Americans feel about living in such a shitty environment?

<comment><USER18> Where in San Diego were you? I am wondering if there is a place in that beautiful city that is rubbish strewn. It's got horrible public transport though, agreed.

<comment><USER17> It was a few years ago, so things may have changed. I was out in the suburbs a bit, staying with a friend (who worked and therefore couldn't give me lifts everywhere). The wasteland looked like it was eventually going to be more suburb, but wasn't actually a building site.

I did find it weird that there were these patches of the city where just nothing was built. British cities are incredibly compact - if it's not built on or being built on then it's a manicured public park, usually fenced. But Aussie cities have odd areas that are just empty, too... must be the relative age of the cities that causes this.

</comment></comment></comment></comment></comment><comment><USER19> > as state DOTs widen highways to reduce congestion, in complete ignorance of > all the data proving that new lanes will be clogged by the new drivers that > they invite.

Let's see a cite to that data, because it seems ridiculous. Obviously if you make a road less congested people may start preferring it to other, more congested roads, but that just means the reduction in congestion is distributed rather than concentrated, and how is that a bad thing?

The entire premise of this article is questionable. The theory is that people will drive more carefully when the roads are more dangerous. From this the argument is that we should make the roads more dangerous in order to make them safer. This is obviously completely counterintuitive so they point to some evidence that it could be true (which itself seems to imply that its veracity lies near the statistical margin of error). The real problem is that it's a false dichotomy. Making the roads more dangerous is not the _only_ way to make people drive more carefully. And alternative ways of encouraging people to drive more carefully are obviously preferable to a method that, at a given speed and level of care, is more dangerous according to the laws of physics.

More than that, this "make the roads dangerous to make them safe" is completely backwards when we're on the verge of commercially available self- driving cars. A self-driving car is obviously not bound by human psychology, so for all of those vehicles, making the roads more dangerous will only make the roads more dangerous.

<comment><USER20> There was an article about people's tendency to soak up additional road space posted on HN fairly recently: [http://www.wired.com/2014/06/wuwt-traffic- induced-demand/](http://www.wired.com/2014/06/wuwt-traffic-induced-demand/)

(You can also see something similar with internet bandwidth. Same principle, I think.)

There's a Wikipedia article about the theory that narrower, signage-free roads are safer on aggregate: [http://en.wikipedia.org/wiki/Shared_space](http://en.wikipedia.org/wiki/Shared_space)

(I don't know/care if these are useful to you - simply a brain dump, as you asked)

<comment><USER21> Imagine if you have an IT company with a server. Your server can handle 1000 concurrent users. It is running slowly because a lot of people try to access it.

So you buy another server. Now you have 2000 users, but once again it is starting to run slowly.

You decide to stop there. Clearly, more servers wont help. You'd just get more and more users.

<comment><USER22> Imagine I get a grant from the local government to open a stall in the middle of town giving away free high-quality coffees. But it has long lines.

So I open another stall next to it but the lines don't seem to get much shorter even though I'm making twice as much coffee.

<comment><USER23> We all know that roads aren't free. If they weren't worth building in terms of increased economic output, however, then city planners would stop building them.

<comment><USER24> That seems reasonable on its face. The reality is that state and federal funding hinges on city planners padding budgets and increasing capacity to meet future growth. Meanwhile, cities and towns put themselves in hock to meet the servicing demands of their infrastructure, requiring more state and federal funding, requiring new projects with padded budgets and increased capacity.

Notice that nowhere in there was a requirement that said infrastructure pays for itself. More often than not, and especially in small towns, it doesn't.

But don't believe me, take it from a civil engineer and urban planner who has done a lot of real research into this phenomenon: [https://www.youtube.com/watch?v=tn7aJ_Ti- co](https://www.youtube.com/watch?v=tn7aJ_Ti-co)

</comment></comment></comment></comment></comment></comment><comment><USER25> How does traffic speed increase with wider lanes, but capacity doesn't?

How many lives are saved by fire trucks, police, etc... being able to get to/from emergencies more quickly? I feel like experimental data will be much more useful than models to measure the impact of 10' to 12' lanes.

<comment><USER26> When speed increases, the safe distance between cars increases as well, therefore reducing overall throughput.

<comment><USER27> Actually, more speed also means cars spend less time on the road, so throughput increases still. Bumper to bumper Traffic jams don't mean high throughput. What is most important is smoothness in flow.

</comment></comment></comment><comment><USER28> The article has 1.2 the amount of words it needs, at least. Apropos.

Strange to use Florida as an example, with an 8-lane local road! Suburban Florida is empty and flat very spread out and every road is basically a highway. People need to go fast because everything is far away. Not like urban environments where most time is spent stopped at corners, not moving.

<comment><USER29> Your statement is not applicable to West Palm Beach or any other locale along the Gold Coast. That area has some of the densest population in the US.

<comment><USER30> Agreed. Tampa, Orlando, and the other big cities are like any others. In the middle of the state or the Everglades, though, you can go miles without even a turnoff.

</comment></comment></comment><comment><USER31> This article completely misses the point of having wider lane path ways. Wider lanes help increase the speeds of vehicles and studies have shown that high speed traffic works far better than slow traffic. Just look up ramp metering where they deliberately keep too much traffic off of highways to maintain speed and maintain safety and maintain efficiency of roads.

The cases where narrow street widths work better are places where there is more stop and go traffic like downtown areas where majority of the residences are crowded with store-front development. There instead of insisting on narrow lanes, you should insist on complete street designs that appropriately designs for all kinds of traffic.

New urbanist movements seem to be behind this kind of lunacy of trying to create traffic conditions more difficult for cars. In New York, this trend has been set of by the Bloomberg administration and is labeled/marketed as traffic calming. It is really traffic impeding and is the center piece design of urban environments. I admit there are various benefits to it, but the underlying motivations are to be anti-gas guzzling vehicles.

<comment><USER32> Your comment makes me think about this a bit differently. I live in NYC, and end up driving through it once every couple of months. While I'm normally sympathetic to people who hate anything that makes things easier for drivers and worse for pedestrians, if NYC is a model for "traffic calming", it's terrible, because I'm very angry and aggressive after 15 minutes of trying to drive in this place. I don't want to drive often, and I don't want to encourage more driving, but I want driving to be less difficult. Maybe make street parking 2-hour-max everywhere so there's room for cars and trucks to stop so they don't stop in the middle of the road, and they're forced to pay for off-road parking overnight, etc. Or something else, I don't know. That sounds severe, but the situation is already ridiculous.

<comment><USER33> > if NYC is a model for "traffic calming", it's terrible, because I'm very > angry and aggressive after 15 minutes of trying to drive in this place.

"Traffic calming" is a euphemism for telling drivers to go fuck themselves. If traffic increases to meet capacity, traffic calming is trying to reverse that. By punishing drivers, and making it incredibly shitty to drive, traffic is reduced.

It's a feature, not a bug.

<comment><USER32> I thought "traffic calming" was to reduce speed and increase safety. My point was that, if you reduce speed all the way to zero, safety is not increased, due to frustration. "Traffic is reduced" is not an accurate way to describe the situation.

<comment><USER34> I'm not a traffic engineer, but if "traffic calming" is to reduce speed and increase safety, then I have very rarely seen it work or be used that way.

Instead, it strikes me as both a tool for non-drivers that are "driver hating", as well as those local NIMBYs/etc that don't want those "crazy speeders" through the town ("think of the children").

Next time that folks discuss putting traffic calming bumps in your community, ask whether you want the emergency vehicles to be slowed down when you or your loved ones are waiting for an ambulance. Consider the extra pollution created by all the slowing down and speeding up.

I have spoken to folks familiar with Cambridge, MA government structures, where they have told me that it has been actively refused to re- time/synchronize stop lights to have a green wave because they want the traffic slowed down. New York City has real green waves (e.g. going up 1st ave). So next time you are driving down Massachusetts Ave in the evening and you hit random red lights for no reason, know that someone has explicitly decided to do this to you.

<comment><USER35> I green wave that goes 30 MPH, instead of 45, sounds like a good idea if you want traffic flow to be pedestrian friendly, though. Race car drivers have to stop, until they learn to just cruise.

</comment></comment></comment></comment></comment></comment><comment><USER36> This article just came out last night, suggesting that road diets are great bang for the buck when it comes to decreasing crashes. [http://bikeportland.org/2014/10/10/less-500000-three-road- di...](http://bikeportland.org/2014/10/10/less-500000-three-road-diets- preventing-37-crashes-every-year-112049)

<comment><USER37> At some point, people forget what the roads are for in the first place. You can also decrease crashes by enforcing a 5 MPH speed limit, right?

</comment></comment><comment><USER38> Seinfeld warned us of the danger of wide lanes quite a while ago : [https://www.youtube.com/watch?v=CwinnODU0yo](https://www.youtube.com/watch?v=CwinnODU0yo)

</comment><comment><USER39> Even if I agree with most of that, I don't think keeping the road wide and using the outside area a bike lanes will work. People are going to see a wide road and drive fast anyway. I suspect you'd have to actually narrow the road, not just reallocate the concrete. But TD;DR maybe that was covered and I'm wrong.

<comment><USER40> Anecdotally, in Vancouver we have narrow lanes in the city, with many streets having all kinds of bike lanes along their sides – both shared and separated. It works quite well, especially the separated ones.

Narrow lanes surely do decrease average driving speed, it's damn uncomfortable to drive fast in traffic, and staying in the lane requires more concentration. I do miss wide Russian lanes sometimes, but the narrow ones are undeniably safer.

<comment><USER41> Separated bike lanes are absolutely wonderful. More of those and I would probably ride my bike more places.

</comment></comment></comment><comment><USER42> About 8 or 9 months ago, they reduced the 3-lane thoroughfare through my part of town to 2-lanes with a bike lane, and narrowed the lanes to about 10 feet. People slowed down at first, but now people go just as fast as they used to, typically 5-10MPH over the speed limit, and some 15 MPH over (that's 50MPH). The radar signs installed as part of the project always read 40, 42, 45 and not just for my car.

As a cyclist, the bike lanes don't really make me feel safer. There is a good margin of space between the bike lane and the car lane, but the bike lanes are really only in effect for half of any given block. The second half of the block, the line between the car/bike lanes is dotted, and cars can legally enter the bike lane, to make right turns. And then of course, anyone parallel parking on the street has to cross the bike lane to do so.

Making the lanes narrower did not make pedestrian crossings any safer, as the road is actually the same width, and you still have to travel the same distance to cross the street. What did make it safer for pedestrians, the installation of flashing yellow warning lights at certain crosswalks, that pedestrians can turn on before crossing the street. Motorists see them and stop for people crossing, and that is a new and welcome effect.

The bike lanes would have been much MUCH better implemented one block south of the main drag on a residential street that runs parallel. Much safer for cyclists. Healthier too, not having to breath as much vehicle exhaust. And probably a more optimal allocation of resources for the citizens. As much as everyone wants to be PC and become friendly advocates of human-powered transport, it really doesn't make sense in this part of town, to increase trip times and emissions for thousands of motorists daily, so the 50 people who choose to ride their bike can have a marginally safer lane to ride in. In Downtown L.A., it is completely different. Downtown, the bike lanes make sense because hundreds if not thousands of people use them. You always see a bike in the bike lane over there. But outside of the heart of the city, many people commute to work and carpool their kids to school and ballet and such. They're not going to ride bikes 5 hours a day to make that kind of commute.

Oh, and where the traffic engineers failed to account for, and accommodate heavy traffic on a couple of heavily-traveled segments of the road, motorists now drive their cars illegally in the bike lanes during periods of congestion.

IMO the project is mostly a failure. The safer pedestrian crossings are a great improvement. But the bike lanes such as they are, and the narrower lanes, just a waste of money. Putting the bike lanes on a side street would have been really great, a win-win for both cyclists and motorists.

<comment><USER43> >People slowed down at first, but now people go just as fast as they used to, typically 5-10MPH over the speed limit, and some 15 MPH over (that's 50MPH). The radar signs installed as part of the project always read 40, 42, 45 and not just for my car.

Radar signs that basically just say "shame on you" are worthless. Traffic enforcement cameras ("speed cameras") that actually hand out fines would have an actual impact. Those speeders would change their ways if they had to pay a fine every time they drove over the limit. Preferably the fine would be scaled based on the driver's income.

<comment><USER44> In my baseless opinion, the "shame on you" radar signs are probably pretty effective. And definitely preferable to robot overlords handing out tickets. And doubly less offensive than charging people more based on income. At least here in the US, we have the concept that all citizens are treated equally in the eyes of the law. I don't want a system that intentionally punishes rich|poor|black|white|smart|dumb people more than any other.

<comment><USER43> Charging based on the infraction _does_ punish poor people more than rich people if you look at how significant the fine is to the person.

Person A makes $10 * 40 hours / week -> $400 / week -> $100 ticket == 25% of weekly gross income

Person B make $100 * 40 hours / week -> $4000 / week -> $100 ticket == 2.5% of weekly gross income

Who is being hit harder? Who will be more deterred from future speeding?

Furthermore, the "robot overlords" won't care if someone is "rich|poor|black|white|smart|dumb". Can you say the same for a police officer?

<comment><USER44> Also, what if someone's wealth changes between the ticket and the penalty? If they are rich when given the ticket, but lose it all, is it still fair to charge them the higher rate?

My point is: changing from an absolute value to a relative one introduces complexities in the system. Philosophically, the law needs to treat everyone the same, which to me, means the penalties are the same for everyone regardless of sex, race, income, height, weight, or any other characteristic. This is encoded in the Constitution. I do not see how two different people, convicted of the same crime in the same contexts, should have different punishments. (Yes, I know it happens, but I think that's a bug, not a feature, and wish it would be cleaned up.)

</comment></comment></comment></comment></comment><comment><USER45> Ah, the old "If I don't wear a helmet, I'll ride more cautiously and never get into a wreck" argument.

<comment><USER46> There is an argument that car drivers are more careful when they see cyclists not wearing helmets.

And also the overall health benefits are better, when you consider that more people will ride without helmet rules.

Only Australia has this requirement.

<comment><USER45> Crap, I was talking about motorcyclists, but didn't specify it in my post. This is literally an argument I have heard from other riders.

</comment></comment></comment><comment><USER47> Please god of good urban planning give the force to Street Art the tagline "BUILD NARROW STREETS" everywhere

</comment><comment><USER48> If you're really interested in the subject and want to read more without dealing with the wanky blogger writing style check out "Traffic: Why We Drive the Way We Do" ([http://www.amazon.com/Traffic-Drive-What-Says- About/dp/03072...](http://www.amazon.com/Traffic-Drive-What-Says- About/dp/0307277194/)).

</comment><comment><USER49> I just rolled out a measuring tape to 12 feet and I'm quite certain my local traffic lanes are nowhere near there..

<comment><USER50> Did you know that two basketballs fit, side by side, through a basketball hoop? Eyeballing things like this is almost never close to right.

<comment><USER51> You can probably cram them through since they are flexible, but they wouldn't fit without some force; a regulation rim is 18 inches inside diameter and a basketball 9.5 inches diameter.

<comment><USER50> Good catch. I saw this demonstrated in grade school, where they were probably using size 6 balls. Nevertheless, most people think it's not even close.

</comment></comment></comment></comment><comment><USER52> Blah.

I remember when the speed limit was raised from 55 to 65. Politicians paraded all kinds of studies from engineers, PhD's and mothers crying on TV. The claim was that blood would run down our streets and highways. The effects of making this change, the "experts" and politicians said, would be cataclysmic.

What happened in reality?

Nothing of the sort. Actually, some of the opposite. Accident and fatality rates went down.

So I call hogwash. Maybe this guy has some sort of bias, financial or political interest in this idea. Maybe it is about hiring a million new union workers across the nation to repaint all of our streets and buy votes for the democratic party in 2016. Maybe it is about giving a few huge corporations juicy contracts to try to buy financial support and votes for republicans.

I don't know. My life is about science and data. So, yes, I do value honest studies with solid data and conclusions. I also know that you can't take a sentence or two our of a study and quote it completely out of context to support your case. When put into context the reality of the study could be very different and the conclusions could be really flawed.

Ask almost anyone who drove pre-65mph how they feel about the change to 65. I would be surprised if anyone said it got worst. It's a lot more relaxed. You don't have to be constantly focused on the darn speedometer or become a human highway patrol detector.

In fact, I think the speed limit ought to be raised to 80mph. People are not suicidal. They'll drive at whatever speed is safe and comfortable for them. On average, today, that seems to be somewhere around 75 to 80mph, except when CHP gets on the road and everything slows down causing traffic backups, etc.

If we are really that concerned that blood will run down streets it is a relatively simple technological matter to legislate that no automobile sold in the US can go faster than, say, 70mph. An automatic speed limiting system could also be put into place to limit speeds everywhere in real time. A low power emitter in every traffic signal in the nation could tell cars what the max speed limit might be and the software in the car keeps you from exceeding it. Done deal.

If the issue is so serious let's just do that. I'd rather have cops devote their time to chasing bad guys than hiding behind a fence to give dumb traffic tickets to all the mommies taking their kids to school during the first week of class (happens almost every year here).

<comment><USER52> I love how HN continues to prove to be a place where only cargo cult mentality is rewarded. Anything outside of that is mercilessly down-voted by the 22 year olds that permeate this mono-cultural society.

It's OK, it's just funny. You still have a few years of reality before you actually get out of the cave and stop seeing the world through shadows on the walls, some of which were painted by your professors in college.

Tolerance is something most people love to talk about just to sound "right" and fit in. In practice intolerance and prejudice are far more common with people who preach it --and behave otherwise-- than in those who do not but rather choose to simply practice it.

Just the way it is.

On HN you can't have a viewpoint significantly opposite that of the underlying HN culture. You just can't.

<comment><USER53> HN is generally more pro automobile so your stance is not "controversial" by the ethos here. I believe posts are getting downvoted because they are needlessly attacking. Your logical flaws don't help either.

<comment><USER52> Well, let's just say I disagree with you. There are no logical issues with my original comment about how a lot of these "the sky is falling" articles are nonsense supported nonsense often in support of underlying political motives. Can't say that's never happened before.

On the attack aspect. Look, HN is characterized by some really dumb back and forth discussions full of senseless nit-picking. I call these "programmer arguments" because it is often impossible to argue with some programmers because they are really good about arguing endlessly about utterly irrelevant minutiae. Like the comments in this thread that got into the idea that there's an argument to be made about drivers being more careful when they see bikers not wearing helmets. And the nonsense back and forth continues.

So yeah, I have grown quite intolerant to nonsense over the last five years or so. I've been really busy and have not read HN in a while. I just came back and see a bunch of the same thing and this intolerant cargo cult.

HN is at it's best when the discussions are contained to technology, startups, software or hardware development and related topics. There's a lot of expertise and value here when it comes to these topics.

The minute HN discussions deviate from that world it all derails. I have this vision -right or wrong- of a bunch of real-life ignorant 22 year olds brainwashed by their college professors desperately trying to play adult with their comments here. I'd be funny if it wasn't so stupid. They have little life experience yet have categorical opinions about everything and are incredibly intolerant of anything outside this cargo cult mentality.

Progress isn't made by those who swim with the current. You have to be willing to swim hard against it if you want to change the world, or at least your little corner of it. Going against the flow is not easy, as evidenced here. It would be called bullying in the real world. Or at least bigoted intolerant behavior.

Here's the good part: Despite what is said or done here, reality is as it is. And this they will eventually learn the hard way on the street, not here. I remember having a conversation about taxation with a 22 year old engineer who worked for me at one of my companies 15 years ago. He had swallowed-up the liberal coolaid whole. Nothing I could say could convince him he was wrong. Ten years later he called me up one day to thank me for what he learned from me (mostly in terms of engineering). He also mentioned he now understood the issues I used to point out regarding taxation. Why? Because he launched his own business and got the experience of now having to hold that cat by the tail.

HN is broken. Keep it to science, tech and startups and all is well. Everything else derails into nonsense kiddie bickering almost instantly.

<comment><USER54> "My life is about science" \- but you refuse to post a link to any science.

That, and weirdly aggressive tone, is why you're being downvoted.

Just asking but do you _honestly_ not know that?

<comment><USER52> Honestly know what?

I am not refusing to post anything. I plant a seed. I know the answer. Anyone can google it just as well as I might be able to. Why does everything have to be spoon fed?

So someone finally was interested enough to research my claims and post a link. Here it is:

[http://www.motorists.org/speed-limits/55-mph- study.pdf](http://www.motorists.org/speed-limits/55-mph-study.pdf)

The article starts with this:

"In 1995 the Republican Congress repealed the 55-mile-per-hour federal speed limit law. At the time, the highway safety lobby and consumer advocacy groups made apocalyptic pre- dictions about 6,400 increased deaths and a million additional injuries if posted speed limits were raised. Ralph Nader even said that "history will never forgive Congress for this assault on the sanctity of human life."

"...a million additional injuries..."

All bullshit as 20 years of history has proven.

So why the tone? Because this HN trait infuriates me.

Someone posts a factually accurate viewpoint that goes against the "HN culture" and they are mercilessly attacked here. It's bullying at it's best. The difference is that while most people just crumble and leave, I don't. And I am not shy about calling bullshit when I see it.

As to my choice to be short and to the point and even use colorful language. Well, I'd much rather listen to a man who presents facts with straight, even sometimes abrasive, speech out of the need to make an impression than waste any time listening to well-crafted, intellectually brilliant sounding, well articulated, refined, non-colorful, non-offensive language that is full of lies and manipulations...you know, like politicians or those on HN who take the time to write great sounding posts with lot's of links and research that, when you get right down to it, are hardly worth a handful of manure.

So there, someone, not me, was smart and inquisitive enough to ask: I wonder if this guy might have a point? And he or she posted a link to a pretty good PDF.

It echos exactly what I said: politicians, misinformed activists and even government agencies painted apocalyptic i ages of what would happen if the speed limit was raised. It was all nonsense. The exact opposite happened. And that is likely the case with this dumb 12 foot vs. 10 foot lane issue.

Of course, none of the HN down-vote kiddies are going to read this and say "Wow, this guy was right!", apologize and learn something.

No, instead they'll find some other justification for their hatred-driven down vote assault and move on to he next guy who dares to stand up for a truth that happens to go counter tho what makes HN kiddies feel good about themselves.

People, grow up.

</comment></comment></comment></comment></comment></comment><comment><USER55> Apples to apples, this does not really apply to SF or even most of the Bay Area.

Perhaps all of Texas, Arizona or NM.

Not here.

I hope some smart Alec SF supe does not get any ideas, reading this.

The bulb-outs at the intersections [1], the rules-dont-apply-to-us cyclists [2], the abundance of parklets and dedicated Muni lanes are already making driving in SF a hugely cumbersome affair. If it isn't already, with its 20%+ grade roads [3].

From my experience living in SF, drivers here are not the most skilled as it is. This will only worsen things.

If Mr. Wiener catches wind of this, I'm certain he will call for miniature lanes, like when he called for miniature firetrucks, when firefighters expressed concern over the width of streets. [4]

[1] [http://sf.streetsblog.org/2014/07/03/bulb-outs-noe- valleys-g...](http://sf.streetsblog.org/2014/07/03/bulb-outs-noe-valleys- getting-them-outer-balboas-got-them/)

[2] [http://www.sfgate.com/crime/article/Bicyclist-sentenced- for-...](http://www.sfgate.com/crime/article/Bicyclist-sentenced-for-fatal-S- F-crash-4736312.php)

[3] [http://www.datapointed.net/2009/11/the-steeps-of-san- francis...](http://www.datapointed.net/2009/11/the-steeps-of-san-francisco/)

[4] [http://sf.streetsblog.org/2014/05/09/monday-speak-out-on- sff...](http://sf.streetsblog.org/2014/05/09/monday-speak-out-on-sffds-push- for-wider-streets-at-city-hall/)

<comment><USER20> I've already read that story about that cyclist who killed a man. Do you have 2 different ones?

<comment><USER55> Here's a TV news report on the incident:

[http://www.youtube.com/watch?v=2EQA_Cm8SKw](http://www.youtube.com/watch?v=2EQA_Cm8SKw)

<comment><USER20> Thanks! This appears to be the same guy though.

<comment><USER55> _Geez! Have you noticed the downvote parade? Have I said something mildly offensive to the sensibilities of the Critical Mass militia?_</comment></comment></comment></comment></comment>


New type of venture capital - <AUTHOR>

I am a VC junior analyst (recent graduate, have been working past year and loving it!). I had a thought a few months ago: I want to angel invest. I love startups, the culture, the community, and I wanted to personally have skin in the game, outside of my job (not a partner, so don't have major share in the carry). This is not possible since I am not an accredited investor. So, no dice. Then I came up with a different angle. What else can I invest, other than money. I'm looking for some validation into my new angle / new idea / new firm. Check out angleround.co to see what it's all about (beta, current traffic 1, this is the first 'release to the public') Also, for those of you that would like to get involved and have interest in venture capital, please do drop us a line. Who knows where this will go. Cheers, entrepreneurs! Here's to thinking different. Let me know what you think. <comment><USER2> I just checked out your site because your "angle" sounds good. Beautiful graphics but poor credibility. You say "tell us enough to get us excited," and then say don't worry about NDAs because that's the way VCs operate. VCs are known and run on their track records. You aren't. Sorry, I've got to know more about you before exciting you.</comment>


Brilliant 3D T-Rex image. - <AUTHOR> http://acreativeuniverse.com/wp-content/uploads/2010/04/pimpsawse.tumblr.com-post-437630844.gif

<comment><USER2> Okay, how does that work?

<comment><USER3> <http://en.wikipedia.org/wiki/3D_image#Wiggle_stereoscopy>

from the article:

"Wiggling works for the same reason that a translational pan (or tracking shot) in a movie provides good depth information: the visual cortex is able to infer distance information from motion parallax, the relative speed of the perceived motion of different objects on the screen. Many small animals bob their heads to create motion parallax (wiggling) so they can better estimate distance prior to jumping."

<comment><USER4> The Wikipedia page mentions Piku Piku. Googling that reveals this example:

<http://blog.start3d.com/2010/01/embedded-piku-piku.html>

It seems to create morphed frames in between the two original shots.</comment></comment></comment>