Boycott systemd - <AUTHOR> http://boycottsystemd.org/ <comment><USER2> I can't access that site because it returns 500 right now, but: Can we please get over it?

Quoting the "Unix philosophy" as the reason to keep things like they were 20 years ago is laughable. I want to get things done, and managing processes using init scripts and daemonization is pain. _Edit: I 'v read the cached version now, and this assumption turned out wrong. The authors see a need to replace sysvinit._

The amount of bad and inconsistent init scripts, messy PID file handling, makeshift service wrappers, defective daemonization and logging workarounds is so much worse than having one place that will handle those ever repeated tasks.

I love that in recent years Linux (as in distributions) got an attitude and actively push things forward, without losing compatiblity to older software. Apple introduced launchd and nobody complained. We start to rely docker and all sorts of new approaches to manage our services and nobody complains. But init is somehow regarded as the holy cow noone is supposed to touch although everybody agrees it sucks.

Even if it's technically wrong: Unix as a platform is now Linux. Everything else is niche products, and we don't have to use the same init mechanism on Linux/BSD/whatever just because we can.

I have deployed the same software on Debian Linux, RHEL Linux and AIX and basically had to reimplement service management scripts for every platform to have the best possible result. How could this get even worse?

<comment><USER3> I don't see a boycott happening. Not unless someone steps in to write an alternative init system, which solves some of the issues openrc and systemd solve, but without systemd's baggage.

taking the discussion out of the opinion level to a more factual level(eg. i like the boot speed of my archlinux machine but the whole consolekit(why did we get that to begin with ?)/logind/ridiculousness, logging and service files vs. startx and grep /var/log is annoying to say the least, but as i said subjective)

on a factual level we have ridiculous bugs specifically caused by systemd that take down your system, and the lead developers saying either i don't care or it's by design. let me bring a few examples:

[https://bugs.freedesktop.org/show_bug.cgi?id=76935](https://bugs.freedesktop.org/show_bug.cgi?id=76935)

> That is the expected current behaviour, "debug" can cause "too many" > messages to be useful anymore if things are broken.

or this one, systemd segfaulting with cgroups off:

[https://bugs.freedesktop.org/show_bug.cgi?id=74589](https://bugs.freedesktop.org/show_bug.cgi?id=74589)

Lennart:

> To make this work we'd need a patch, as nobody of us tests this.

There were a few other recent ones. When your new init system consistently takes down your operating syste, because of stupid bugs, and the lead developers say we don't care, and even block efforts to fix these issues, you should indeed worry.

[https://plus.google.com/111049168280159033135/posts/Kd57G8s1...](https://plus.google.com/111049168280159033135/posts/Kd57G8s1cTD)

In fact Greg KH jumped in to play daddy, and wrote a patch where tom gunderson commented that that patch would not be merged as it's not clear what problem it solves.

edit: some say openrc is the one. here's a comparison:

[https://wiki.gentoo.org/wiki/Talk:Comparison_of_init_systems](https://wiki.gentoo.org/wiki/Talk:Comparison_of_init_systems)

<comment><USER4> runit (from daemontools) might not start things up in parallel, but it's a whole lot simpler and reliable. Phusion uses it instead of upstart in their base docker VM.

Also a lot of enterprise shops use daemontools and runit, because they just fucking scale.

<comment><USER5> I'm from Phusion.

Runit is great as a tool to manage your own daemons. But as a general init system for distributions? Not so much. Just take a look at the /sbin/my_init system that we wrote for baseimage-docker and what kind of functionality it adds on top of Runit, to give you an idea of why Runit by itself is not enough. Runit also performs no dependency management (i.e. starting one service before another) so it's quite painful in certain situations. For example, if you have a background queue daemon that depends on PostgreSQL, then you have to manually make sure that the daemon is not started until PostgreSQL is available. Otherwise you get tons of useless error messages as your daemon keeps getting restarted.

<comment><USER4> No problem, just wrote a tool for that:

        waitport [-u] port [timeout (float)] # -u = UDP instead of TCP

        go get   github.com/steakknife/my_init/waitport
        go build github.com/steakknife/my_init/waitport
        # creates waitport bin here

<comment><USER4> Renamed to [https://github.com/steakknife/devops_toolchain](https://github.com/steakknife/devops_toolchain) to avoid confusion.

A collection of individual tools that can be cherry-picked to solve nitty- gritty problems.

</comment></comment></comment></comment></comment></comment><comment><USER6> Tom Gundersen discussed the move to systemd on the Arch Linux forums a couple of years ago.

[https://bbs.archlinux.org/viewtopic.php?pid=1149530#p1149530](https://bbs.archlinux.org/viewtopic.php?pid=1149530#p1149530)

Summary:

        0) it is hotplug capable
        1) we can know the state of the system
        2) it is modular
        3) it allows dbus/udev to go back to doing the task they are meant to do
        4) we can reduce the number of explicit ordering dependencies between daemons
        5) we get a lot of security/sandboxing features for free
        6) systemd service files can be written and distributed upstream
        7) systemd is a cross-distro project
        8) logind will finally deliver on what consolekit was supposed to do
        9) systemd is fast

<comment><USER7>
      0) That's not the init systems job.
      1) That's not the init systems job. Use something like http://cr.yp.to/daemontools.html
      2) Less modular than any init system out there. Having *everything* (including a dhcp deamon soon) in PID 1 is not modular just because you can configure it.
      3) See 1.
      4) Never bothered me, but fair enough.
      5) That's not the init systems job.
      6) Not if the path's differ. E.g. are debianized.
      7) So was sysvinit.
      8) That's not the init systems job.
      9) It actually is.

Edit: And if you downvote me, at least add an explanation please. Thanks. I'd like to know if I'm factually wrong or you just disagree.

<comment><USER8> You failed to mention _why_ it's not the init system's job. An init system which is aware of what's going on can have a lot of advantages.

In the end djb's daemontools are nothing more than an init system on top of an init system. So why not include it in the main init system?

<comment><USER9> > daemontools are nothing more than an init system on top of an init system

What do you mean by that? That it isn't PID 1? Apparently it can be made to run as PID 1. But you can keep the (in my opinion) brilliant design of daemontools and use successors such as s6 are designed to run either as PID 1 or as a plain old daemon (which is nice if you've not got full control of a machine).

[http://www.skarnet.org/software/s6/index.html](http://www.skarnet.org/software/s6/index.html)

I've been using s6 to manage a few things, and some features I like are:

\- allow a group to manage (stop/restart) certain processes using Unix file permissions

\- arrange things in a tree. My toplevel s6-svscan starts a second s6-svscan which starts a handful of related processes. These all inherit the same user and environment vars which makes config easy.

<comment><USER10> Have you tried runit? If so, could you tell me how it differs from s6? I like runit, but if it's better, it's better.

<comment><USER9> I have not tried runit. s6 is actively maintained; I don't know about runit (on the other hand, runit is in Debian while you must compile s6 yourself). The author of s6 has a (very biased of course) comparison or various supervisors:

[http://skarnet.org/software/s6/why.html](http://skarnet.org/software/s6/why.html)

The big feature s6 has that runit lacks seems to be the ability to wait without polling on some event (process started). I haven't used this much myself, but even given that some process has started, it doesn't necessarily mean that it's initialized and ready to do what you expect.

</comment></comment></comment></comment></comment></comment><comment><USER11> > an abhorrent and violent slap in the face to the Unix philosophy

I'm tired of all this UNIX philosophy crap. I have been using Systemd for more than a year now, on Archlinux, and it has been a delightful experience.

It works out of the box and it gets a lot of things right. Journald is quick & easy to use and a real help in finding problems. No more searching around in log files and grepping. Dependencies between services are handled by the init. Services start with maximum parallelism. Writing .service files is really easy.

It simply has better UX than any other init system, and it's supported by a lot of distros. This means standardization and progress. No more developer time wasted on sysvinit scripts.

The posted link is the same FUD that I have been reading for the last year on various forums. Even if systemd can be a single point of failure, it's still way more stable than anything we have used before.

<comment><USER12> I'm tired of people who are tired of hearing about UNIX philosophies and call it crap.

</comment></comment><comment><USER13> Okay, well, while I agree with most of the points they make, there just isn't a viable alternative. I maintain noop Linux (nooplinux.org), it started using OpenRC, but when udev was merged into systemd, things got very complicated, eventually the switch was made. Systemd is very fast, the 'init.d' scripts are way better, udev work very well...I don't mind thinking about moving back away from systemd (because I really do have a love-hate relationship with it), but what am I supposed to go back to? OpenRC/SysV-whatever? Heck no. Upstart? Nope. ...is there even an alternative that makes sense? Because moving back to SysV would be a step back.

<comment><USER14> >it started using OpenRC, but when udev was merged into systemd, things got very complicated

I got past that by using eudev with OpenRC on Gentoo.

<comment><USER15> For uncomplicated systems (such as virtual machines, servers and whatnot) there's mdev in busybox.

</comment></comment></comment><comment><USER16> "Unix philosophy" seems to be one of those phrases that everyone likes agreeing with because you can use it to either justify or condemn anything you like.

E.g. you could perfectly plausibly make the argument that systemd's return to inetd-style service starting (on-demand and in-parallel through socket activation) is a lot more unix-philosophy-like than the SysVinit way.

<comment><USER17> Agree, but SysV-init isn't notably unixy. In general, SysV distros raced to embrace and extend away from the mainstream. That created lots of un-unixy subsystems that live on in linux. Quick wave in the direction of three - NFS, wacky IPC systems, SysVinit.

SysVinit is complicated - it wants to be a DSL but is still a shell hack- together. It's inflexible - it's a dependency tracking system, but you can't easily adapt it for userspace launch control, or as a build tool. It doesn't do one thing well. (e.g. doesn't reliably contain a process tree, there are still situations where you want to use pid files or complicated ps greps).

Init is a hard problem. From what I can see all the unix derivatives have made a mess of it. I've had fleeting attempts at writing my own, and I definitely made mess.

In the absence of the good, I reckon the simple becomes the standard. In modern BSDs there's a script called init, it gets called at startup and does nothing for you. I reckon we should judge challengers to init against that.

</comment></comment><comment><USER18> The author of systemd, Lennart Poettering busts some systemd myths in his blog post [http://0pointer.de/blog/projects/the-biggest- myths.html](http://0pointer.de/blog/projects/the-biggest-myths.html)

<comment><USER19> There's one thing that the boycott post gets right, that Mr Poettering doesn't address, which is:

 _> 2\. systemd's journal files (handled by journald) are stored in a complicated binary format._

Mr Poettering tackles the myth that _configuration files_ are binary (they are very obviously not).

That said, I am not sure how to get the journaling data in an Upstart system, nor in a sysvinit one.

</comment></comment><comment><USER20> They'd get _much_ further if they actually came up with a better alternative.

Even _if_ all of there points were objectively true, it doesn't matter when sticking with the old init is so much worse in many ways.

People aren't picking systemd because it's perfect, but because both the mess of init scripts it is replacing, and alternatives like upstart,is seen as worse/too lacking.

EDIT: Btw. this just got me to install systemd on one of our dev/test Debian boxes at work, to start testing it.

</comment><comment><USER21> I'd rather see init's problems fixed (i.e. start services in parallel), but systemd is far better than upstart (edit: got it to load at last, I see it's not by upstart fans, so ignore that last part).

That said, a lot of systemd seems like a really stupid idea to me, e.g. binary logs, the massively increased SPOF size, and the "do everything" mentality. Unfortunately, I don't know of any distros that aren't using it now (edit: I didn't even realise Slackware was still a thing...), and upstart is even more of a joke than systemd.

<comment><USER22> What's wrong with binary logs? Seems like an improvement, given how they can be cryptographically 'sealed' to help tamper detection, and have indexes built in [1].

[1] [http://www.freedesktop.org/wiki/Software/systemd/journal- fil...](http://www.freedesktop.org/wiki/Software/systemd/journal-files/)

<comment><USER23> Binary logs are pretty annoying because your standard tools for searching through them no longer works.

tail, less, grep, wc and similar tools are rendered useless. Newer tools like logstash or Splunk are also going to have issues reading your binary logs. It's not really a wise thing to break the tools that most people use every day, it's just going to make them hate you.

<comment><USER20> Which only means that you need to pipe the output of journalctl to your standard tools. It hardly renders any of you tools useless.

<comment><USER21> Not all tools operate on stdin. For that matter, this doesn't fix the millions of people and organisations who will have custom tools and processes.

All the binary logs are going to do is make people have a cronjob to extract them regularly into a readable format.

<comment><USER20> > Not all tools operate on stdin.

So pipe it to a file and operate on that. Or give the broken tool /dev/stdin as its filename. Or give it a fifo as a filename and "journalctl | /path/to/fifo.

> All the binary logs are going to do is make people have a cronjob to extract > them regularly into a readable format.

For those who insist on that, yes. Most of them will presumably have logrotate set up anyway, so it's hardly more complexity. Or you can run a syslog, and trivially set up systemd to forward the log entries to that.

Meanwhile the rest of us will enjoy the ability to do things like specify a start and end time with command line switches when trying to find stuff in the log, filter by priority, filter by user, filter by pid. seeing only data since last boot, get the journal as JSON instead of having to rely on brittle text parsing of entries that contains less information.

Regarding the last point, here's an example of an entry from journalctl -o json-pretty:

      {
            "__CURSOR" : "s=56750fa36ad94eb99c00e7fd6854c400;i=2;b=2f533403d7a041e7a389e3a7090942de;m=172e6e4;t=4f7c809a2f61d;x=79a98b8a5116658a",
    	"_SYSTEMD_CGROUP" : "/system/cron.service",
    	"_SYSTEMD_UNIT" : "cron.service",
    	"SYSLOG_FACILITY" : "10",
    	"SYSLOG_IDENTIFIER" : "CRON",
    	"_CMDLINE" : "/USR/SBIN/CRON",
    	"MESSAGE" : "pam_unix(cron:session): session closed for user root",
    	"SYSLOG_PID" : "2398",
    	"_PID" : "2398",
    	"_SOURCE_REALTIME_TIMESTAMP" : "1398345421294046"
      }

<comment><USER24> Pipe that into [http://stedolan.github.io/jq/](http://stedolan.github.io/jq/) and you could do things.

</comment></comment></comment></comment></comment></comment></comment><comment><USER25> Em .. no, thank you. I think that systemd is a good step in the direction of unifying different distributions. Also, many argument presented on that page have been debunked or are actually good things.

<comment><USER26> I agree, i find it very hard to believe that so many distos would make the wrong choice here.

<comment><USER27> It's the best option at the moment arguably not perfect but better then anything else out there.

I wish the owner of that website would would make a better alternative instead of complaining.

<comment><USER28> I think the concern is that systemd is following a rapid "embrace, extend, extinguish" path, and very quickly will have achieved critical mass and become somewhat unstoppable.

There's nothing wrong with saying "I like Linux, but it's becoming Lennartix and I'm concerned."

</comment></comment></comment></comment><comment><USER29> Lennart is rapidly becoming the new Drepper.

As long as characters like this persist Linux as a direct end user system is going nowhere, and it will remain a lower level component abstracted away by higher level platforms, as in Android or Chrome OS.

</comment><comment><USER30> At [https://wiki.gentoo.org/wiki/Talk:Comparison_of_init_systems](https://wiki.gentoo.org/wiki/Talk:Comparison_of_init_systems) all of the features that are unique to systemd are immediately something that I'd rather not have integrated.

</comment><comment><USER31> For me it always feels like people who are bashing on systemd never actually used it. I was very concerned about systemd for long time. And nowadays I use it on all my machines/servers. And it just makes my life so much easier. I'm happy. I like it. I can agree with lot of points on this website. But still systemd makes my happy. So sorry, but no.

<comment><USER4> For 99% of uses, esp desktop, laptop, embedded... it's great.

For that tiny percent of use cases where services can do all kinds of crazy things and there needs to be extra control, other things like supervisor, foreman_god, daemontools/runit come into play. There are use-cases not many people have to deal with or even exposed to, yet are important considering the impact (say downing a major service like Gmail).

</comment></comment><comment><USER32> 'systemd flies in the face of the Unix philosophy: "do one thing and do it well," representing a complex collection of dozens of binaries'

So, a collection of lots of single-purpose binaries that work together flies in the face of "do one thing and do it well". I kinda stopped reading at this point, which was sadly quite high up the page.

<comment><USER33> I think the point is you can't replace each of those binaries with alternatives. The monolithic nature of systemd is not just a function of the raw number of binaries involved.

<comment><USER34> > I think the point is you can't replace each of those binaries with > alternatives

Is there any reason why you couldn't do so?

Found this chart: [http://www.freedesktop.org/wiki/Software/systemd/InterfacePo...](http://www.freedesktop.org/wiki/Software/systemd/InterfacePortabilityAndStabilityChart/) Note the columns "Reimplementable Independently" and "Known Other Implementations"

<comment><USER35> Something being (theoretically) possible doesn't mean it's practical.

The attitude of the systemd (And Freedesktop.org folks in general - and please don't give us the usual Lennart cry of "No really, we're NOT the freedesktop.org people!" \- despite all of these projects sharing a tightly knit community of people steering them) devs and their treatment of their projects has meant for some you basically do things their way or the highway.[1]

It's already a pain in the ass to strip udev out to keep using it if you've decided to not use systemd. And that's just taking one portion of the system that was promised to be kept easily independent of the rest of the muck, not trying to make other services work within the framework of a systemd system.

As it becomes the standard across all of the major distros, I find it hard to believe that it will become easier to separate systemd parts from one another than it is now, because there becomes even less incentive to do so.

I don't have much of a horse in this race, because I've long since migrated the vast majority of my production systems to FreeBSD and OmniOS, and out of the few that I have that are running linux still, some of them are using systemd. I don't particularly like it, but instead of complaining about it and doing nothing, I've minimized the impact I feel from it.

[1] [https://news.ycombinator.com/item?id=7534583](https://news.ycombinator.com/item?id=7534583)

</comment></comment></comment></comment><comment><USER36> I see this as related and it is less than a month old: [http://www.muktware.com/2014/04/linus-torvalds-happy- systemd...](http://www.muktware.com/2014/04/linus-torvalds-happy-systemd- author-kay-sievers/25151) [https://plus.google.com/u/0/+TheodoreTso/posts/K7ijdmxJ8PF](https://plus.google.com/u/0/+TheodoreTso/posts/K7ijdmxJ8PF)

I am not much of a systemd fan so I may be biased but it is interesting read anyway.

</comment><comment><USER37> Okay, I like to think as myself as an open minded individual. I'm not a systemd fanboy either, I just research and use what I believe it's better for myself. There is a reason why I can't consider the anti-systemd guys seriously: It all seems FUD to me. Take for example point 8, "you have to reboot to update systemd. Okay, not really, but the update might go wrong!". Really?

Going point by point:

1\. As the site says, systemd is both an init system and a collection of programs that make sense to have in a system. One can already strip most of everything from it (I think only journald is mandatory), and there is usually a stable api between every component, so one can simply replace them.

In fact, I believe that half of the complains about systemd would disappear if it all the tools were developed in a different repository and not under a "systemd umbrella" (Isn't one of the major point pro-BSD the fact that the base system is all developed together?)

2\. If you want to use systemd but have plain-text logs, journald can pass everything to syslog and similar daemons. What everyone forget is the bonus that journald provides: no more "cat /var/log/*.log | grep <program> | sort -u" and hope that applications log in the same format, I have everything in a single place and can browse them by unit, by user, by time, by urgency...

3\. I can agree with that. But it's not that sysinitv or upstart worked on non-linux systems (without ugly hacks)

4\. And? I'm not sure what's the problem here. udev and dbus are mandatory by pretty much anything that's not a .sh script nowadays.

5\. Okay, fair point. "It assumes that users and admins are dumb" can you really blame them?

6\. Fair point again, systemd is bigger than sysinitv. But that's almost saying that we should all use microhttpd instead of nginx/apache because it's smaller.

Also the simple fact that it's included in RHEL 7 mean that it got audicted by RH, which make me feel safe.

7\. That's just FUD. Here's Gnome 3.10 running on OpenBSD: [http://undeadly.org/cgi?action=article&sid=20140219085851](http://undeadly.org/cgi?action=article&sid=20140219085851)

Gnome will depend on systemd when under wayland, that's instead a fact. Actually, on logind, which has an api that anyone can reimplemnt ([https://blogs.gnome.org/ovitters/2013/09/25/gnome-and- logind...](https://blogs.gnome.org/ovitters/2013/09/25/gnome-and- logindsystemd-thoughts/))

8\. Not true, again. Right now, on my system:

       pgrep -l systemd
          1 systemd
          354 systemd-journal
          386 systemd-udevd
          766 systemd-logind
          1190 systemd
          1754 systemd

Also, I still fail to see why "it's big, it will fail" is a thing. What matters is code quality, not size.

9\. Fair point.

10\. This might or not be possible, I don't have much experience in writing unit files so I don't really know the limits.

11\. Nobody is forcing anyone to adopt systemd. It's getting adopted because distributions and developers think it's better.

And after months/years of complains about systemd, I still haven't seen anyone trying to produce anything that has the same advantages for sysadmins and programmers.

Really, that's how it feels: "I'm going to complain and complain and complain, but I won't lift a finger to change the course of events".

Can anyone make a point in favor of sysinitv (or against systemd) without bringing in abstract concept as "Unix philosophy" and plain wrong facts?

<comment><USER38> 6\. is a big deal for me. 9 CVE since 2011? that's crazy in combination of "single point of failure".

<comment><USER39> Yeah, but keep in mind that:

1\. It now has a lot more attention focused on it, so it will get more scrutiny.

2\. Unix admins have always been wary of the bleeding edge; distros are adopting systemd today, but those distros themselves are unlikely to see wide production adoption for a year or two.

3\. If the systemd team's processes are not up to snuff, a major distro will fork it and run it themselves. If the criticisms have any merit, others will follow. It's why open source is such a great model for critical system software: it's as pure of a meritocratic model as you can get (well, if you accept the fact that merit is based on adoption.)

Basically, any new critical unix process is going to have these types of issues. The fact that systemd has a lot of support basically ensures it will get a lot of attention and bugs/security holes will be fixed.

<comment><USER40> Still, the simpler something is, the less scrutiny it needs in the first place. Mind you, I think even sysvinit is too complex for PID 1. PID 1 should do the bare minimum trhat the kernel expects of it (taking care of orphaned processes, handling shutdown requests) and leave the rest to other programs.

<comment><USER39> On some level I agree with you, but if you look at the things that Apple is able to do with OS X and timer coalescing [1], that central point of coordination becomes critical. You need a mechanism for starting and stopping all things, not just daemons, that plays by a specific, defined set of rules so you don't have multiple processes trying to do the same thing.

On another level, I feel the "unix philosophy" of having a lot of interchangeable modules taking care of small, simple tasks hurt it: each level of abstraction has a performance hit, and having to support multiple components in a modular way makes change management a nightmare. There's something to be said for the elegance of tightly integrated components: you can make assumptions that you couldn't otherwise make in a more modular system. I can see how it would be a problem if systemd were proprietary, but it's open source.

[1] [http://www.apple.com/osx/advanced- technologies/](http://www.apple.com/osx/advanced-technologies/)

<comment><USER41> You are right that loose coupling carries a performance hit. Certainly, if your only goal is to increase the boot speed of a desktop Linux box, then systemd makes a lot of sense. That said, there are many other goals and many other kinds of boxes, which, among other reasons, is why the tide is turning against systemd.

<comment><USER39> "Performance" can many different things, all of which are useful in different contexts. It could be lower power consumption, faster thread performance, more I/O, lots of things.

<comment><USER41> agree. So far, the only 'performance' case that I've seen made for systemd is in desktop system bootup time. Certainly it won't make my threads go faster or cause significantly lower power consumption, or give me 'more I/O'.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER42> For Linux to keep evolving, part of evolution is mutation, the strong will flourish while the weak will die.

Regardless of what init system is right or wrong, the beauty of the Linux ecosystem is we can afford for different distributions each to make different decisions.

Systemd seems functionally better than both sysvinit and upstart and it certainly doesn't seem to be the root of all evil like this article makes out.

I don't believe that everyone boycotting systemd over what's currently out there will aid linux in any way.

<comment><USER43> When everything will use systemd (because all the "core system" is starting to depend on it, wayland included) how do you evolve out of it? Rewrite the entire lower level of your system AGAIN? That does not help evolving rapidly, in my opinion.

<comment><USER44> That's funny. So what you're saying is that we shouldn't rewrite the lower level because it'll be harder to rewrite it later on.

<comment><USER43> No, and I'm sorry I was not able to explain that properly. :)

We should not (re)write a lower level where all the components are so coupled we will be unable to change one of them with a better alternative without changing the rest.

</comment></comment></comment></comment><comment><USER23> We just install daemontools on all of our servers for our own stuff and let the system packages use whatevers the default in the distro, they seem to live happily together.

I suspect that one issue with systemd is that it aims to solve very real problem, but they are problems that not many noticed. Most of the stuff that's highlighted as benefits of systemd are things I never experienced, either I don't thing advanced enough or the issue has already been addressed by the distro.

Most of us are just going have some daemon/process that we want to start at boot and for that purpose systemd is going to look like massive overkill and overly complicated. That might be mostly a documentation issue, systemd could benefit for a "So you want to start at process" guide.

</comment><comment><USER45> Does anyone know if this quote is true?:

"Since systemd is very tightly welded with the Linux kernel API, this also makes different systemd versions incompatible with different kernel versions."

I was pretty meh about the whole systemd thing, but having to change userspace when swopping out kernels is a spectacular disadvantage. Imagine having to downgrade your distro whenever you need to test against older kernels --- madness.

This is especially bad with ARM/embedded stuff where one often runs a modern userspace with an older kernel.

<comment><USER46> In my experiece, upgrading the kernel to a newer one is not a problem. What can happen, though, is that an upgrade of userspace will suddenly require a kernel-feature not present, if you run an ancient board-support-package with a 3.0-kernel or so in 2014! (happened to me with a BSP for a Freescale i.MX6).

So, if you have archlinux tracking the latest and greatest systemd, uptrading userland can make your machine no longer bring up everything (completely). But in my case the kernel is from 2011...

<comment><USER45> I have an i.MX5 BSP with a 2.6.xx era kernel :(

Can you give an example of the "no longer bring up everything (completely)"?

<comment><USER46> After putting a current arch-linux rootfs[1] on the box[2], it seems to come up, just network and console seems to be misconfigured, but this, I think, I had to fix the last time also. So: indeed the current systemd seems to work on a iMX6 running a 3.0 kernel.

[1] ArchLinuxARM-imx6-latest.tar.gz from [http://archlinuxarm.org/developers/downloads](http://archlinuxarm.org/developers/downloads)

[2] Phytec PhyFlex i.MX6 [http://www.phytec.de/de/produkte/system-on- modules/produktde...](http://www.phytec.de/de/produkte/system-on- modules/produktdetails/p/phyflex-imx-6-3.html)

<comment><USER46> ### addendum ###

Recent systemd doesn't seem to realize that ethernet and the serial console device are actually there, it's waiting for dev-ttymxc3.device and sys- subsystem-net-devices-eth0.device ... but both are statically compiled in. So there is some issue with kernel 3.0.x.

<comment><USER46> I was missing one config option from the README, now it works!

</comment></comment></comment></comment></comment></comment><comment><USER47> Given that both systemd and upstart exist, it would seem that it is time for a next generation init. And given that Ubuntu has now accepted systemd, it has critical mass and should be the new standard.

"Doing one thing and doing it well" is a fine guide for system tools, but does not apply to everything - look at the kernel, or Gnome for instance.

</comment><comment><USER48> > Consider migrating to BSD, Plan 9 or something similar, if things get really > out of hand.

I can understand suggesting to migrate to BSD, but Plan 9? Seriously?

And what's the purpose of the "Open Source Tea Party" picture? This surely is not the only picture of Lennart in existence.

</comment><comment><USER12> I fell in love with FreeBSD's init style, which is what I switched to when the move Archlinux made broke my systems. Due to virtualisation demands I had to switch back to Linux, and chose Funtoo (a Gentoo fork) with the OpenRC init system.

I've never been happier.

<comment><USER49> Isn't FreeBSD's init system monolithic?

</comment></comment><comment><USER50> <meta name="author" content="VR and DnE">

Seems the authors forgot to give themselves the credit they deserve.

[https://forums.darknedgy.net/profile.php?id=589](https://forums.darknedgy.net/profile.php?id=589) [https://forums.darknedgy.net/profile.php?id=373](https://forums.darknedgy.net/profile.php?id=373) [http://billyest.es/About_Me](http://billyest.es/About_Me)

</comment><comment><USER51> Considering the adoption and improvements, I'm on board with the "standardization" of distros with systemd.

Can't stand upstart and it's "Oh you wanted to restart your daemon, but I won't run the pre-start/post-start/post-stop actions you've configured me to", but that's just me.

</comment><comment><USER52> > Contribute to and _use distros like Slackware_ and CRUX that follow > traditional Unix paradigms.

Made my day. Emphasis mine.

<comment><USER53> The good thing about Slackware is that it acts as a timemachine for how Unix/Linux used to be back in the mid-90s.

When the neckbeards comes around complaining about "Unix philosophy" you can always tell them to use Slackware. And then watch them go silent.

</comment></comment><comment><USER54> I don't know much about systemd, so I can't say either way.

So long as I can still get syslog style plain text logs, then I have no objections. Unix and text log parsing is unparalleled. If simple text log parsing and manipulation is removed (all binary with only xml or json), then I'd be very opposed to systemd.

<comment><USER55> The short story is systemd's logs are "binary", but they have tools to transform them into whatever plaintext format you like.

</comment></comment><comment><USER56> I hate systemd. I will avoid it when every possible. It is an abomination. I hate upstart even more.

<comment><USER57> Did you read the page? It doesn't advocate upstart.

<comment><USER56> Yes, I did read it. The reason I threw in upstart is because these inits have similar design philosophies.

</comment></comment></comment><comment><USER58> Systemd got a huge boost due the involved from Red Hat. But then most of the distros are adopting it, even Debian and Ubuntu. I don't see a reason but still if you want to stay out of systemd better use Gentoo or other "non" major distro.

<comment><USER25> The reason is that it's awesome.

</comment></comment><comment><USER59> I recently installed and investigated PC-BSD for this very reason; a friend who's a BSD user commented that systemd has been driving BSD adoption very hard recently. I intend switching to PC-BSD for personal and work use within the year.

</comment><comment><USER60> Does the old "good standard will have 2 or more implementations" apply here?

</comment><comment><USER61> Cached: [http://webcache.googleusercontent.com/search?q=cache:zylqvGo...](http://webcache.googleusercontent.com/search?q=cache:zylqvGo21_oJ:boycottsystemd.org/)

(the site is unreachable at the moment).

</comment><comment><USER4> Until there's a viable alternative, it looks like whining.

</comment><comment><USER62> I hate to be personal, the guy leads systemd is indeed a genius, but genius could be more destructive, his way to do things for linux/unix is too intrusive for whatever he has done so far.

it's always good to try a disruptive way on the side before it matures and gets accepted gradually, however with the direct support from Redhat(where he is an employee) this systemd thing carries much more power than a typical open source project, sigh.

I would rather stay with sysvinit instead of something like this.

I think he should be employed at Microsoft to help them revamp their OS or whatever, make it or break it there, but please stay out of OSS.

</comment><comment><USER63> They single out Lennart Poettering but don't have the guts to write their own names under their arguments. You can't take this serious.

</comment><comment><USER64> The "debate" about systemd is like the "debate" about global warming: all the people with any knowledge of the issue fall on one side, and the opposition consists largely of the ignorant and butthurt.

Systemd has won by being vastly superior to any alternatives. I suppose it's all right to use something else but the community has embraced systemd as the correct solution, and you lose community support and assume all the risk of breakage if you do not stick with systemd.

<comment><USER65> > Systemd has won by being vastly superior to any alternatives.

Systemd is better than Upstart, but it won in no small part due to politicking and strategically merging other projects that everyone else depends on.

</comment></comment><comment><USER66> tl;dr systemd crashes systems, is incompatible with other distros and OSes, adds admin difficulty, breaks applications, and introduces security holes

\---

systemd was created in order to improve the speed of booting up your system. I'm serious. It was created because waiting a minute to boot up your machine once was too long.

In order to accomplish those faster boot times, they ripped out the stock init system model, and created a monolithic, non-portable, non-backwards- compatible, kernel-version-specific, Noah's Ark of API calls and custom tools which use binary formats and incompatible IPC methods to start programs that were never designed to run that way. They made obsolete virtually every aspect of the operating system which used to work with existing applications to start and maintain the running of userland programs. For faster boot times.

Of course, most of you don't care because you don't have to maintain your system, as long as it just works. What does this mean for people who _do_ work with the system?

First off, building tools that work with the system are now more complex. It used to be you could use any i/o or ipc method to do anything you wanted. Now you have to look up and call and API call - and if the API call you want isn't in systemd's tool, or it doesn't expose it in a way you can use in your program, tough. Better become a C programmer fast.

Second, better be careful how you update your system. Every version of systemd, and any software it depends on, could crash your entire machine if a bug is introduced. I weep for the poor sysadmins who push out an update to thousands of machines only to find a strange bug which takes them all down, all because systemd decided having an enormous codebase was worth booting 20 seconds faster.

I hope you've got money for a security audit. systemd has had nine security vulnerabilities in the past four years. For comparison, sysvinit has had one CVE - in 1999. I haven't found any CVEs or security bulletins for upstart, which sounds amazing to me.

When it comes time to porting your application to Linux, you don't get to just write it in a way that would normally work on most Unix-like systems (which would, at this point, be virtually every operating system that isn't Windows or Mac OS, and now Linux). Now you have a new porting target specifically just to get your application to _run_ , and then you get to deal with the normal porting issues.

At the end of the day, systemd is a culmination of two ideas, with one result. One idea is that a "superior design" with "advanced features" is the only benchmark in which we should design and run a system. The other idea is that we don't need to keep compatibility with legacy systems or alternative platforms, because fuck users, admins, developers, security analysts, distro maintainers and portability teams, we want faster boot times , damnit. And it's Advanced! The result? A big fucking mess of complexity that breaks everything that came before, introduces security holes, makes it more difficult to modify or maintain your system, and breaks compatibility with other systems (even Linux ones).

But aside from all that, systemd is great.

</comment><comment><USER67> It is Linux. Let systemd live and if you don't like it, switch to upstart. No one is stopping you.

<comment><USER43> It's (slowly) becoming impossible.

<comment><USER57> This is the "TempleOS impulse". The feeling of disgust with byzantine complexity, driving an impulse to start clean and chase the money changers out of the temple

<comment><USER12> Upvoted for mentioning TempleOS, I have never been more frightened when reading about OSs.

</comment></comment></comment></comment><comment><USER68> There must be already a name for this particular fallacy, when a bunch of people considered themselves "knowing the [only] right direction" and especially "destroying and discarding everything to build it up from scratch as they know will be the best for all". A-la those uneducated, ignorant, but cook-sure and self-confident lower-class revolutionaries in Russia hundred years ago who were unable to grasp that "evolved [social] system" has some subtle "laws , forces and reasons" behind it and that uncomprehensive, even unreadable philosophy or a naive, oversimplified model [of economics] is much worse than no philosophy or model whatsoever. Self-regulated (and especially evolved) complex systems are "smarter" than any bunch of individuals ,)

</comment><comment><USER69> Just pointing out it's not that difficult to "roll your own" linux distro. It'll take you an afternoon if you haven't done it before... and you can very well choose to keep using sysvinit if you want (my personal distro will use sysvinit probably until the end of the year when I have time to figure out how to integrate systemd).

</comment><comment><USER69> I think the website is missing the legal disclaimer "Paid for by Canonical (because we're bitter)".

<comment><USER57> Again no, Canonical wants to sell services around Ubuntu, which will soon be based on systemd, by decree of Mark Shuttleworth.

Wanting to do that, it doesn't make sense that they would shill for Slackware at the top of the page.

</comment></comment><comment><USER69> The Canonical fanboys are just upset they lost out on their inferior technology and now are trying to do everything possible to stall it. systemd is unquestionably a big step forward, Upstart is only a step to the side. There is a reason the serious linux distros (no, Ubuntu is not serious, it's a toy for newbies to use on their desktop) have all chosen systemd. There is also a reason some of them tried Upstart and decided it was not good.

<comment><USER57> No, the Canonical fanboys are following Mark Shuttleworth in accepting systemd as the future for Ubuntu.

This is a different set of people.

</comment></comment><comment><USER70> This is why we can't have nice things.

</comment><comment><USER71> I'm getting code 500 error, but I'm guessing a Republican has been discovered to be somehow related to systemd.

</comment><comment><USER72> If this person had been running systemd, this website would still be up.</comment>


How Obama Can Say "We Don't Have A Domestic Spying Program" Without Lying - <AUTHOR> http://techcrunch.com/2013/08/07/how-obama-can-say-we-dont-have-a-domestic-spying-program-without-lying/

<comment><USER2> Don't think of it as a unconstitutional surveillance system. It's more like a mandatory backup system for all electronic and voice communications (one that only the government has access to).

I'm sure that it will never be abused.

<comment><USER3> [https://news.ycombinator.com/item?id=6012941](https://news.ycombinator.com/item?id=6012941): _Government Builds Free Cloud-Based Backup for an Ungrateful Nation_.

<comment><USER2> Awesome. Thank you for the link!</comment></comment></comment>


Hubble directly observes the disc around a black hole - <AUTHOR> http://www.physorg.com/news/2011-11-hubble-disc-black-hole.html

<comment><USER2> Straight from the European Space Agency, cutting out the physorg blogspam: <http://www.spacetelescope.org/news/heic1116/> (press release), <http://www.spacetelescope.org/videos/heic1116a/> (video), [http://www.spacetelescope.org/static/archives/releases/scien...](http://www.spacetelescope.org/static/archives/releases/science_papers/heic1116.pdf) (paper).

PhysOrg: just say no.

<comment><AUTHOR> Noted for the next time I submit a space related article. Thanks for the heads up.

</comment></comment><comment><USER3> The way they're using the gravitational lensing here blows my mind. From what I understand they're using a distant galaxy as a part of the telescope itself to resolve objects behind it. Insane.

Surely this constitues the largest scientific instrument ever?

<comment><USER4> That's a pretty standard usage of gravitational lensing. It's a giant magnifying glass in space, and they've used them as such since like forever.

<comment><USER5> Wikipedia describes <https://secure.wikimedia.org/wikipedia/en/wiki/Twin_QSO> ("Old Faithful") as the first identified gravitationally lensed object.

So, "since forever" is 1979, which makes me feel old.

<comment><USER6> In astrophysics, anything more than 15 years old is considered "archeoastronomy."

<comment><USER3> Makes a change from web programming, where the equivalent period seems to be about four months.

</comment></comment></comment></comment></comment><comment><USER7> So can anyone tell me why a galaxy is considered to be anything more than a large (and 3-dimensional) black-hole accretion disk?

<comment><USER8> Galaxy's from huge black holes at their center they don't from around huge black holes that predate them. Also galaxy's have several black holes of various sizes where an accretion disks only includes smaller chunks of matter. They can even have more than one super massive black holes if two older galaxy's collide.

<comment><USER9> I was going to say "also, galactic stuff never actually falls into the central black hole", but I'm wrong-ish. According to [http://en.wikipedia.org/wiki/Future_of_the_universe#Stellar_...](http://en.wikipedia.org/wiki/Future_of_the_universe#Stellar_remnants_escape_galaxies_or_fall_into_black_holes) it's expected that on a timescale of 10^20 years all the stars (or rather, stellar remnants, since stars will have burned out long before) will either fall into galactic black holes (10%) or get ejected from galaxies entirely (90%).

So, I guess we've got that to look forward to.

</comment></comment></comment><comment><USER10> "directly" is a little bit of an exaggeration

<comment><USER11> Should it have been "generally relatively"?

</comment></comment><comment><USER12> Lens Flare</comment>


Looking for cofounder - <AUTHOR>

I'm looking for a cofounder to help me disrupt the GIS industry. I'm looking to create the 280 slides of GIS.<p>The goal would be to apply to YC for the winter session. Anybody here interested? <comment><USER2> Hi, I graduated college with an undergraduate degree in Geography, specializing in GIS. My professional background is software development, and a few years back I transitioned into user experience design.

I'm wondering what, specifically, you're looking to "revolutionize." ESRI's suite is ugly, complicated and crash-prone compared to, say, Manifold, but Manifold has little traction in the market. It's like Word and OpenOffice.

GIS is a super-broad product category that support everything from photogrammetry to spatial analysis (think demographics, computing safety of bike paths, lines of sight for signage) across both vector and raster data with arbitrary reference points (did you know that most geographic data sets aren't globally georeferenced?).

Making a web-based clone of Powerpoint as an excuse to reinvent Objective C and Cocoa in JavaScript is comparatively easy. Your statement makes me skeptical that you know anything about the market at all.

<comment><AUTHOR> That's the problem. The GIS market is too broad. The ESRI products ate inaccessible to most people. They cost too much, and are too difficult to use. Precisely because they are targeting professional cartographers.

Raster algebra isn't something normal people need.

I don't want to create a product for highly trained cartographers. I want to create a product for me (someone who wants to create simple information graphics).

</comment></comment><comment><USER3> In another life, I would have been interested, but I'm too busy with other stuff right now. I endured the pain of ArcGIS for a few years in my last job.

I don't know what specific problems you are looking to address first, but have a good read of the ESRI forums. They are a treasure trove of business ideas. You might also be able to get your first users there by solving their ArcGIS problems.

</comment><comment><USER4> Possibly... Are you a fellow developer or a suit?</comment>


Out in the Great Alone (2013) - <AUTHOR> http://www.espn.com/espn/feature/story/_/id/9175394/out-great-alone <comment><USER2> Thanks, best read in a while.</comment>


North Korea to launch 3G network - <AUTHOR> http://www.bbc.co.uk/news/technology-21546877

<comment><USER2> Now you can download speeches of your leader 10 times faster.</comment>


Java Polyfill for the Browser - <AUTHOR> https://www.javapoly.com <comment><USER2> To others trying to use this demonstration: Be patient with the page, as it has to download quite a few JAR files in order to be ready to compile and run any test code. To verify that the javapoly is ready to run your code, open the web developer console and wait for it to say "Java Main started". Additionally, first-time compilation will also need to download additional JARs for the demo code to run. Generally speaking though, the compilation time is a good 5-10 seconds on my computer for the demo code, so be sure to not just spam the compile button like I did :)

      ----

Just a friendly note to the author of this page: The total download size of this page's underlying Java resources are much larger than I realized (maybe a collective 30-40MB). Given that I waited almost 5 minutes after clicking "Compile & Run!" for nothing to happen (because I had clicked it well before the runtime JARs had fully downloaded), I would suggest to at least add a progress bar or something to let users know when they can actually compile and run the demo code, in addition to some acknowledgement that the code is compiling. This is definitely an interesting project though.

<comment><USER3> Yeah, Doppio needs to download the entire JDK to run, since it's a full- featured JVM (JRE for running Java programs, JDK for javac so it can compile them). Compressed, it's ~30MB.

The authors of this project can preload the JDK with a progress bar and stash it into IndexedDB, since Doppio's file system, BrowserFS, supports arbitrary backends [1].

[1] [https://github.com/jvilk/browserfs](https://github.com/jvilk/browserfs)

<comment><USER4> Why isn't http caching sufficient?

<comment><USER3> If the authors compressed the JAR files into a single bundle, storing the data into a BrowserFS-created IndexedDB file system removes decompression/extraction overhead on subsequent visits.

If they didn't.... then it might be sufficient, but I am not sure how well the browser cache handles large files! How long until it evicts them? Is there an upper bound on the size of cached items? etc.

<comment><USER5> I am only familiar with Firefox, where the default is 43.75MiB, anything larger than that is not cached.

There's a `browser.cache.disk.max_entry_size` setting that defaults to 51200 (50MiB), however the code also has an explicit override that no item larger than 1/8 of the total cache size (as dictated by `browser.cache.disk.capacity`, default 350MiB) is ever cached, hence the 43.75MiB limit.

All these settings can be changed, obviously, but I suspect few people ever touch them.

I assume other desktop browsers have similar default limits, while mobile browsers probably have a much lower threshold.

</comment></comment></comment></comment></comment><comment><USER3> Lead author of Doppio here! This is quite cool. I don't recognize the authors of this work, so I was unaware of the project and was surprised to see it on the front page of HN!

If you find any issues with Doppio or have any requests, feel free to open up an issue on our GitHub issue tracker.

<comment><USER6> doppio sounds awesome. from the paper:

Numeric support. Direct support for 64-bit integers would enable languages to efficiently represent a broader range of numeric types in the browser. The DOPPIOJVM uses a comprehensive software implementation of 64-bit integers to bring the long data type into the browser, but it is extremely slow when compared to normal numeric operations in JavaScript.

\--

how far is this from being solved?

<comment><USER3> Thanks! I hope Doppio can become useful to many more people. :)

There is a proposal for value types [0] that Niko Matsakis [1] and Brendan Eich [2] talked about a couple of years back and could be used to implement 64-bit numbers in JS, but I'm still waiting for an implementation or a more complete proposal. Looks like it might be dead in the water, as the proposal hasn't been edited in quite some time, but I do not have my finger on the pulse of browser standards so I could be wrong.

[0] [http://wiki.ecmascript.org/doku.php?id=strawman:value_object...](http://wiki.ecmascript.org/doku.php?id=strawman:value_objects)

[1] [http://smallcultfollowing.com/babysteps/blog/2014/04/01/valu...](http://smallcultfollowing.com/babysteps/blog/2014/04/01/value- types-in-javascript/)

[2] [http://www.slideshare.net/BrendanEich/value- objects](http://www.slideshare.net/BrendanEich/value-objects)

<comment><USER7> You could use (the compiled and optimized version of) the implementation we have in Scala.js: [https://github.com/scala-js/scala- js/blob/master/library/src...](https://github.com/scala-js/scala- js/blob/master/library/src/main/scala/scala/scalajs/runtime/RuntimeLong.scala) It is significantly faster, especially for arithmetic operations, and dramatically so for division, remainder, as well as `toString()` (up to 100x speedup). It also contains the unsigned variant of operations (for java.lang.Lond.divideUnsigned for instance).

<comment><USER3> Oh, nice! I'll take a look at that when I next get the chance. I assumed that Closure's Long library, which is based on GWT's Long implementation, would be well-optimized, and never looked into an alternative.

</comment></comment></comment></comment></comment><comment><USER8> Maybe someone could make Rhino[0] run in this, so we can run Javascript in Java in Javascript! Yo dawg!

[0]: [https://developer.mozilla.org/en- US/docs/Mozilla/Projects/Rh...](https://developer.mozilla.org/en- US/docs/Mozilla/Projects/Rhino)

<comment><USER3> Actually, the master version of Doppio can run Rhino AND Nashorn!

(I'm the primary author of Doppio.)

<comment><USER8> Awesome, and can we run Doppio in Rhino run in Doppio then? Recursive Atwood's law!

<comment><USER3> Haha, I've actually tried to do this. The only missing link, I believe, is to add a Nashorn/Rhino backend to BrowserFS (Doppio's file system library) so that Doppio can access the filesystem that Rhino is running in to load the JDK.

If that sounds like fun, I take pull requests [0]. :)

[0] [https://github.com/jvilk/browserfs](https://github.com/jvilk/browserfs)

</comment></comment></comment></comment><comment><USER9> I have an experimental version of chromium running with the JVM somewhere on my HD. It's pretty easy to do with CEF/JCEF.

Two thoughts:

I always imagined something like this should use the <object src="app.jar" /> tag. If you consider that someone could build a browser again with java in it, (like I have) then it would be good to design a polyfill such that, it allows for a native version to exist (and then doesn't run) Also using the same mimetype for jars, classes and source files seems non optimal.

It would be really good if gwt,doppio,teavm all agreed on a single api facade for targeting the browser API. I think that would really put some steam behind the underlying idea here.

<comment><USER3> > It would be really good if gwt,doppio,teavm all agreed on a single api > facade for targeting the browser API.

Unfortunately, that is impossible due to differing requirements; I've actually talked with the teavm and bck2brwsr folks [0]. Doppio requires asynchronous function calls to support preemptive multithreading. TeaVM, GWT, and bck2brwsr all map Java methods directly to synchronous JavaScript methods, preventing them from supporting multithreading.

This is actually one of the larger differences we describe in the academic paper that sets Doppio apart from those projects and Emscripten [1].

[0] Start of the conversation: [https://groups.google.com/d/msg/plasma-umass- gsoc/uuZk09CGIM...](https://groups.google.com/d/msg/plasma-umass- gsoc/uuZk09CGIM4/EsTx_Lq3TcYJ)

[1] PLDI 2014 paper (Sorry, I know I'm linking this a lot in the comments thread, but I promise it's a fun read!): [https://plasma- umass.github.io/doppio-demo/paper.pdf](https://plasma-umass.github.io/doppio- demo/paper.pdf)

<comment><USER10> To my knowledge TeaVM supports multi threading. See the async demo: [http://teavm.org/](http://teavm.org/)

'Async demo that shows how TeaVM can translate multithreaded applications with synchronization primitives.'

Also see this effort trying to unify the APIs: [http://dukescript.com/](http://dukescript.com/)

<comment><USER3> Interesting! A cursory glance at the source code looks like they are doing some form of stack splitting at synchronization points, denoted by method annotations. Note that they reimplement the class library and eschew compatibility with traditional Java programs, so I'm not completely sure how general purpose their threads are. I tried finding some writeup about them, but I suspect the code is the documentation. :)

I haven't checked in with this project since we last talked a few years ago, so it's nice to see notable progress! Thanks for the pointer.

</comment></comment></comment></comment><comment><USER11> This should have a DK: prefix= data plan killer. I was browsing on my phone and realized that it was downloading a lot of libraries. It can be especially a problem when data roaming in Europe.

</comment><comment><USER12> Should show a loading progress indicator for the demo because that took ages & I thought it was broken until I inspected Console.

</comment><comment><USER13> Huh - could this run existing Java tools like Google Closure Compiler in the browser? That would be handy for simplifying distribution, especially since the Java installer started bundling crapware.

<comment><USER3> The last time I checked, doppio can run the Closure compiler [0].

[0] [https://github.com/plasma- umass/doppio/issues/317](https://github.com/plasma-umass/doppio/issues/317)

</comment></comment><comment><USER10> What is the difference of this to doppio? A new approach from some of the doppio authors?

Also if someone says this is useless an interesting use case could be e.g. a hybrid navigation application [https://karussell.wordpress.com/2014/05/04/graphhopper-in- th...](https://karussell.wordpress.com/2014/05/04/graphhopper-in-the-browser- teavm-makes-offline-routing-via-openstreetmap-possible-in-javascript/) or portable native apps using a webview

BTW: I got lots of errors in the Firefox console saying 'Error: Assertion failed: A non-running thread has an expired quantum' although the example works (should have a progress bar :))

<comment><USER3> The Doppio authors (me) are completely uninvolved; this is an independent effort! This project makes it a bit easier to integrate Doppio and use it out- of-the-box.

I suspect the assertion failure is caused by some of their modifications to Doppio's start up code to pause and extend the main thread's runtime.

<comment><USER10> Thanks! As you seem to be the author of browserjs too :) ... will or does doppio/browserjs support the Java memory mapping API?

<comment><USER3> You mean this [0]? I have not implemented it, but it _might_ be possible to do...

[0] [https://docs.oracle.com/javase/7/docs/api/java/nio/MappedByt...](https://docs.oracle.com/javase/7/docs/api/java/nio/MappedByteBuffer.html)

<comment><USER10> That would be really cool :) !

</comment></comment></comment></comment></comment><comment><USER14> It's nice to see this work taking Doppio into new places. For an overview of Doppio, BrowserFS and the DoppioJVM, here's a video presentation mostly based on a talk given by John Vilk at PLDI 2014. Unfortunately, there's no audio, but the slides should be easy enough to follow.

[https://vimeo.com/106106738](https://vimeo.com/106106738)

FIXED - forget this video, watch John deliver it at Microsoft Research! [http://research.microsoft.com/apps/video/default.aspx?id=238...](http://research.microsoft.com/apps/video/default.aspx?id=238749&l=i)

<comment><USER3> And here's a video presentation of John Vilk delivering his PLDI 2014 talk at Microsoft Research. This one has audio! :)

[http://research.microsoft.com/apps/video/default.aspx?id=238...](http://research.microsoft.com/apps/video/default.aspx?id=238749&l=i)

</comment></comment><comment><USER15> My browser hangs for ten seconds as soon as I try to load the page, followed by an unresponsive script error.

I'm on a pretty anemic computer, but there's got to be a way to keep my browser responsive while it loads in everything it needs.

<comment><USER16> I finally had to kill safari on my iphone 4. Which is admittedly old.

</comment></comment><comment><USER17> Excellent execution, and very cool idea.

Somewhat in jest let me say, "People are complaining that JavaScript is a terrible language. Great, let's put Java in the browser." Now we have an even worse language to code in for the browser.

Note: jvilk explains the perfectly valid reason for this library in another comment below.

<comment><USER18> Having Java's powerful multithreading constructs available in the browser is a pretty big deal, I think.

<comment><USER19> As I understand the Doppio paper, they just simulate JVM threads in synchronous JavaScript. So there does not seem to be added performance benefit at least.

It's still a very neat hack, though!

[https://plasma-umass.github.io/doppio-demo/paper.pdf](https://plasma- umass.github.io/doppio-demo/paper.pdf)

</comment></comment></comment><comment><USER20> My browser froze when loading the website which apparently uses the polyfill. Everything as expected.

<comment><USER21> Write once, crash everywhere! For everyone!

</comment></comment><comment><USER22> <script type="text/java" src="[http://www.yourdomain.com/jimboxutilities.jar"></script>](http://www.yourdomain.com/jimboxutilities.jar"></script>)

having text/java as MIME type - instead of at least looking up the correct one in Wikipedia makes this implementation look quite uggly on the first sight. [https://en.wikipedia.org/wiki/JAR_(file_format)](https://en.wikipedia.org/wiki/JAR_\(file_format\))

Also I cannot imagine a single valid usecase for this.

</comment><comment><USER23> I suppose Clojure devs needn't learn ClojureScript anymore. ;)

<comment><USER3> And Scala devs don't need to learn Scala.js; Doppio runs Clojure and Scala. :)

(Joking; both of those projects are pretty great, and have different goals from Doppio.)

(Also, Scala in Doppio is... uh... quite slow. As you may imagine, if you are familiar with Scala's compilation process.)

</comment></comment><comment><USER24> Kotlin, the "better Java" language by JetBrains, can also compile to JavaScript.

[http://try.kotlinlang.org](http://try.kotlinlang.org)

<comment><USER25> Which to me appears to be the better way around, since it generates static JS instead of having to compile Java every time, as well as having to set up a JVM and whatnot.

<comment><USER3> It's better if you are writing new code for the web and want to use a different language, but Doppio is better if you need compatibility with existing JVM code. The goals are different.

</comment></comment></comment><comment><USER26> There's a good reason every major vendor killed off Java applets in the browser. This is probably the worst idea since Windows 95 on the Apple Watch.

<comment><USER27> The main reason is not present in this implementation, which is that clients could execute arbitrary lower-level code in a separate process which the browser was powerless to make secure.

</comment></comment><comment><USER28> First I thought this was a belated April fools...

But it seems to download crazy Java stuff and I get "threadpool.ts:83 Uncaught TypeError: Cannot read property 'run' of undefined" with Chrome 50.

</comment><comment><USER5> License is ISC, in case anyone is wondering.

They don't mention it anywhere, but you can find it in the package.json file in their git repo.

<comment><USER3> ISC is the default license for NPM modules when you `npm init`, so I am not sure if that's their actual license.

Doppio itself is under the MIT license.

<comment><USER5> Regardless of their intent, it is the license with which they released it.

</comment></comment></comment><comment><USER29> [http://i.imgur.com/x12SjIU.png](http://i.imgur.com/x12SjIU.png)

</comment><comment><USER30> I'm always amused when a new and "better" (browser) technology's website makes my browser hang up.

<comment><USER3> The main goal of Doppio was never speed -- it was compatibility [0]. It's actually a JVM interpreter at present, leading to noticeable slowdown over a native JVM. Thus, there are many opportunities for performance improvements!

A recent contributor is starting to add a JIT to Doppio, which is a step in the right direction [1].

[0] Our academic paper from PLDI 2014 has more details, although the project has evolved since then (it's now JDK8 compatible, for example): [https://plasma-umass.github.io/doppio-demo/paper.pdf](https://plasma- umass.github.io/doppio-demo/paper.pdf)

[1] [https://github.com/plasma- umass/doppio/pull/443](https://github.com/plasma-umass/doppio/pull/443)

</comment></comment><comment><USER31> The most difficult part (I think) of writing a JVM is the concurrent garbage collector. Is this making use of Javascript's garbage collector to do the heavy lifting? Or do they implement their own GC in Javascript? Also, I'm wondering how they are handling concurrency.

<comment><USER3> Doppio uses JavaScript's garbage collector. (As a result, it cannot support weak references.) As for concurrency, thread quanta are mapped to JavaScript events, so Doppio can emulate preemptive multithreading. Doppio potentially preempts a "thread" at each function call.

The nitty gritty details are in the PLDI 2014 paper [0]. Some details have slightly changed, though (e.g. DoppioJVM supports JDK8 now).

[0] [https://plasma-umass.github.io/doppio-demo/paper.pdf](https://plasma- umass.github.io/doppio-demo/paper.pdf)

<comment><USER32> Once ES6 support is everywhere, you should be able to use WeakMap and WeakSet.

[0] [https://developer.mozilla.org/en- US/docs/Web/JavaScript/Refe...](https://developer.mozilla.org/en- US/docs/Web/JavaScript/Reference/Global_Objects/WeakMap)

<comment><USER3> Actually, those are not sufficient to implement weak references, and have a much different use case! With WeakMap and WeakSet, the _keys_ are weakly referenced, hence the names. If you have a WeakMap, you can't produce a value stored in the map without a strong reference to a key.

You can actually polyfill WeakMap and WeakSet. You can't do the same for weak references.

<comment><USER3> I misspoke -- you can polyfill WeakSet, but you cannot polyfill WeakMap, since you do not know when you can shrink the map. (But you still cannot use it to emulate weak references, since you need a strong reference to get data out of the map.)

</comment></comment></comment></comment></comment><comment><USER33> It'd be interesting to see if they could get multithreaded support with web workers. Good stuff!

<comment><USER34> You can use simulated threads with JavaPoly, which allows you to utilize the full Java threading model (including locks). If you enable the native jvm, you get true threads. The reason you wouldn't want to use WebWorkers as a primitive for building threads is that the javascript memory model doesn't allow for shared memory, so you would take a huge performance hit while crossing the serialization boundary for virtually every memory access. You'd be better off just using the simulated threads at that point.

<comment><USER35> Just a note: shared memory is coming and I think Firefox Nightly has an experimental version that you can enable in about:config.

<comment><USER3> It's true that SharedArrayBuffer is coming, but there's no way to share _objects_ from what I understand. Since Doppio maps JVM objects to JS objects, it cannot take advantage of shared array buffers to emulate shared memory threads.

<comment><USER35> Well, at some point, all objects are just a blob of bytes.

<comment><USER3> Well, if we represented objects with a blob of bytes, we would have to implement our own garbage collector and manage our own heap, as object references would just be a pointer that points into an array somewhere.

For interop with JavaScript, there's a usability difference between a JavaScript object and a blob of bytes, although that could be overcome with an object "mirror" that proxies operations appropriately.

Our approach was to leverage the existing GC and language features that browsers already have.

</comment></comment></comment></comment></comment></comment><comment><USER10> If someone wants to jump directly to the sources :)

[http://git.javadeploy.net/jimsproch/JavaPoly/tree/master](http://git.javadeploy.net/jimsproch/JavaPoly/tree/master)

</comment><comment><USER36> The only thing that came to my mind was "why put yet another abstraction in the browser?".

Then I realised the answer was probably "because they could".

Someone will write a C compiler in Java and stuff it in the browser next...

<comment><USER3> Actually, Doppio is an artifact from my own research, so there is a very good reason "why" [0]! Basically, if you want to re-use your existing, well-tested code in the browser, it is quite difficult. The browser environment is very different from the environment that most programs expect. Doppio bridges the gap between the environment that these programs expect and the environment that the browser presents, making it possible to bring a full JVM into the browser that can run complicated, unmodified programs.

[0] Doppio: Breaking the Browser Language Barrier paper from PLDI 2014: [https://plasma-umass.github.io/doppio-demo/paper.pdf](https://plasma- umass.github.io/doppio-demo/paper.pdf)

<comment><USER37> From a technical because-we-can standpoint this is really cool, but I am having a hard time imagining actual use cases that warrant running a JVM in the browser. For modern web applications it is too slow (judging from your paper), so perhaps abandoned legacy applications?

Have you encountered any practical use cases?

<comment><USER3> Yes; the paper mentions CodeMoo.com, which the University of Illinois created independently of us to teach basic programming skills to kids [0]. The file system component is readily used by the Internet Archive for their MS-DOS collection [1]. A number of other instructors approached me regarding using Doppio for in-browser IDEs, but Doppio is somewhat cumbersome to integrate into webpages, and never had the time to dramatically improve its documentation and ease-of-use. I believe that is a more fundamental barrier to using Doppio than its performance, especially since you can run Doppio in a WebWorker to avoid some of the responsiveness issues.

Also, note that Doppio is an interpreter, so there is significant interpreter overhead. Using a JIT compilation approach would improve performance, and a contributor is currently working on a basic implementation. I honestly believe that it could become significantly faster with additional work, but as a single person with other projects, I lack the resources to do this work myself.

[0] [http://www.codemoo.com/](http://www.codemoo.com/)

[1] [http://ascii.textfiles.com/archives/4924](http://ascii.textfiles.com/archives/4924)

</comment></comment></comment></comment><comment><USER38> Every time I read "polyfill" I think it has to do with pixel graphics.

<comment><USER39> I was expecting a routine in JavaScript for a fast implementation of 2d polygonal texture filling. I was disappointed as this was something about loading Java in a browser.

</comment></comment><comment><USER40> Other useful hint to authors: the Starter Pack seems to be missing on the server ...

</comment><comment><USER41> It would be interesting to see how this performs, when it comes, in WebAssembly.

<comment><USER3> It would require a complete rewrite; I commented previously [0] describing how WebAssembly seems inappropriate for Doppio, and also discussed similar thoughts about SharedArrayBuffer [1]. Also, the main source of slowness is due to the fact that Doppio uses a JVM interpreter and does not JIT; it could be much faster than it currently is with additional engineering.

[0] [https://news.ycombinator.com/item?id=11656373](https://news.ycombinator.com/item?id=11656373)

[1] [https://news.ycombinator.com/item?id=11655922](https://news.ycombinator.com/item?id=11655922)

</comment></comment><comment><USER42> You can kiss your data plan goodbye after visiting this. Exercise caution.

</comment><comment><USER43> Cool! It would be great if it could a little bit faster tho.

</comment><comment><USER44> Madness. No thanks!

</comment><comment><USER45> Wow speechless</comment>


Paul Graham's Keynote at Pycon 2003: The Hundred-Year Language - <AUTHOR> http://www.paulgraham.com/hundred.html <comment> kris-s I think with the slowing progress of single threaded performance modern languages require three essential features if they want to be "main branches" of the language evolutionary tree.

1\. easy parallelism

2\. easy networking

3\. managed memory

<comment><USER2> Why managed memory? The consensus seems to be that this gets in the way of predictable performance. GC is also non-trivial to parallelize.

<comment><USER3> Where is this consensus stated? The JVM seems to do quite well.

<comment><USER2> People typically don't use Java for performance-sensitive real-time-ish applications. Most modern games are written in C++ still. Operating system kernels are written in C. When I think Java, what comes to my mind is something like LibreOffice.

<comment><USER4> > _People typically don 't use Java for performance-sensitive real-time-ish > applications. Most modern games are written in C++ still. Operating system > kernels are written in C._

Those are 1/100th or less of the type of code people write everyday, in startups, enterprise, cloud apps, even regular desktop and mobile apps...

> _When I think Java, what comes to my mind is something like LibreOffice._

That's written in C++

<comment><USER5> C & C++ are #2 and #4 on the Tiobe index fwiw. It's not like real-time is a niche.

<comment><USER4> Real time is indeed a niche (though a big one), but also it's hardly the reason C and C++ are #2 and #4 on Tiobe.

<comment><USER5> Video games are like a 43 billion dollar industry, and that's just a small slice of software that has real time requirements. Real time is very much a mainstream need. Hacker news just tends to be a bit of a bubble because people focus so much on web development and business logic here.

<comment><USER4> > _Video games are like a 43 billion dollar industry, and that 's just a small > slice of software that has real time requirements._

But still a tiny slither on what most programmers do. Most programmers (the overwhelming majority) do neither video games nor real time.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER6> Does anyone know why PG doesn't comment on HN anymore?

<comment><USER7> Doesn't directly answers your question, of which I suspect parenting very high on the likeliest reason — as that is the reason I've seen others provide for him stepped down and out from YC. But you can see from his last major period of activity [https://news.ycombinator.com/threads?id=pg](https://news.ycombinator.com/threads?id=pg) ends with his departure blog post: [https://news.ycombinator.com/item?id=7493856](https://news.ycombinator.com/item?id=7493856) and the top comment is his wife hinting that Mr Graham was overly consumed by managing hacker news ;)

</comment></comment><comment><USER8> Hard to believe this does not mention Haskell or functional programming ... but then again that was a Pycon talk from 2003.

<comment><USER9> Any language that forces a particular programming paradigm is IMHO never going to be all that great. Java forced OOP on people in ways it shouldn't have. Functional languages force immutability in ways they shouldn't.

<comment> augusto-moura Any language forcing concepts _or not_ , will never be all that great. Just look at PERL and C++, in my opnion they have a much more bad language design than Java and Haskell

Not be that great is in the very nature of anything that can be "quality measurable" by humans. If "quality measurable" was or will be ever a thing

</comment></comment></comment><comment><USER10> FORTRAN, COBOL and LISP are nearly 2/3 the way there.

</comment><comment><USER11> An essay of the same name is in his book 'Hackers and Painters', which I recommend. His idea of the language you use influences how you think struck me several years ago.

</comment><comment><USER12> I do have this brochure about a C conference from 2072 entitled "C the language for 2172?" just can't find the link at the moment

</comment><comment><USER13> Btw, from 2003 to 2019 Java evolved (syntax and JVM) much more than Python. So who is in the dead end now? )

<comment><USER14> [https://trends.google.com/trends/explore?date=all&geo=US&q=j...](https://trends.google.com/trends/explore?date=all&geo=US&q=java%20programming,python%20programming)

<comment><USER15> I think your methodology may be a bit flawed: [https://trends.google.com/trends/explore?date=all&geo=US&q=j...](https://trends.google.com/trends/explore?date=all&geo=US&q=java%20programming,python%20programming,javascript%20programming)

<comment><USER16> Interesting. Do you know more about what's going on here? As in, why the results don't match expectations.

</comment></comment></comment></comment><comment><USER17> "Object-oriented programming offers a sustainable way to write spaghetti code. It lets you accrete programs as a series of patches. Large organizations always tend to develop software this way, and I expect this to be as true in a hundred years as it is today."

As Apple and other companies have demonstrated, OO libraries and frameworks are also a useful way to promote a hardware platform by facilitating the adoption of proprietary languages and code by third-party application software developers.

<comment><USER18> What does that have to do with OO? Is there something unique about OO that makes it superior for "facilitating the adoption of proprietary languages and code by third-party application software developers"?

<comment><USER19> I think they were just railing against the notion of self-contained libraries and frameworks that are capable of being used by developers in binary form. I'm guessing a hobbyist who cares infinitely more about maximizing their own mental stimulation than about creating things and solving problems for other people on a professional basis.

Nothing wrong with pure hobbyists, it just leads to weird conversations where different people clearly value different things for unspoken reasons, then get into unusually polarized arguments about engineering practices until everyone realizes that some people are talking about fun stuff they mess around with between classes, and other people are trying to figure out how to solve an immediate problem for an employer who's already given them a bunch of money in exchange for solving problems. Those are two very different conversations.</comment></comment></comment>


Young Saudis See Cushy Jobs Vanish Along with Nation's Oil Wealth - <AUTHOR> http://www.nytimes.com/2016/02/17/world/middleeast/young-saudis-see-cushy-jobs-vanish-along-with-nations-oil-wealth.html <comment><USER2> Even without oil prices dropping, Saudi Arabia's days are numbered. No one knows exactly how much oil they have left, but they have been pumping seawater into the ground for years now. This doesn't signal that their oil is drying it up, but it is less plentiful than before. Any country that relies on natural resources for its wealth will suffer when those resources dry up and are not replaced with some form of productions. When was the last time you bought something made in Saudi Arabia?

The USA made Saudi Arabia via Ibn Saud, and it will unmake it via Iran. The sanctions were lifted on Iran, because the USA saw the writing on the wall years ago about Saudi Arabia drying up. It needs to reposition itself as an ally of the next major middle eastern oil producer. Not only does Iran have oil, but it has some of the largest natural gas deposits in the world. [1] After years of conflict, and a proxy war in Yemen, Iran is likely to do anything to ruin Saudi Arabian. This means any power over production that Saudi Arabia used to wield via OPEC will be nullified once Iran is developed by Big Oil.

Its an end of an era. The war in Yemen keeps aggression pointed outward, but as soon as the populace tires and the payoffs stop coming it will turn inward. Another government will be recast as tyrants and despots, and the world will watch it fall.

[1] [https://en.wikipedia.org/wiki/List_of_natural_gas_fields](https://en.wikipedia.org/wiki/List_of_natural_gas_fields)

<comment><USER3> I don't think the US "made" Saudi Arabia. My recollection is that the Saud family defeated their local rivals and established the Saudi state in the 20s and 30s, and that American political involvement with Saudi Arabia really only began towards the end of WW2.

<comment><USER4> It was the British who backed the Saud family initially. Towards the end of the Ottoman empire. They gave the Sauds advisers and military support.

<comment><USER5> No the British backed the Hashemites (the plot of Laurence of Arabia;)) the territory was split between the 5 sons of Hussein ibn Ali of which only Jordan currently remains Saudi Arabia, Iraq, Syria and a few other regions that do not exist today were lost to secterial conflict.

[https://en.m.wikipedia.org/wiki/Hashemites](https://en.m.wikipedia.org/wiki/Hashemites)

<comment><USER4> ? It's an easily checked fact.

[https://en.wikipedia.org/wiki/Ibn_Saud](https://en.wikipedia.org/wiki/Ibn_Saud)

Excerpt: "After World War I, he received further support from the British, including a glut of surplus munitions. He launched his campaign against the Al Rashidi in 1920; by 1922 they had been all but destroyed."

<comment><USER5> "Sharif Hussein bin Ali rebelled against the rule of the Ottomans during the Arab Revolt of 1916.[4] Between 1917 and 1924, after the collapse of Ottoman power, Hussein bin Ali ruled an independent Hejaz, of which he proclaimed himself king, with the tacit support of the British Foreign Office. "

Looks like the Brits love supporting everyone ;)

<comment><USER4> Yep. Pretty much anyone not Ottoman.

</comment></comment></comment></comment></comment></comment></comment><comment><USER6> Economically and socially, Saudi Arabia is a mess. And it's not going to get better in the long run, even if oil prices rebound and they feel some degree of a respite. Technology is changing, and oil isn't going to be sufficient for the Saudis to keep the lid on things domestically.

When most countries industrialize, they go through significant social and economic changes. Saudi Arabia got to skip a lot of those changes, and the end result is that they're ill-prepared for when their reserves have dried up. Their non-oil sectors are practically non-existent, with very little non-petro industry in the country at all. They've got huge social stratification problems, and they have to deal with religious opposition to modernization and diversification (for fear of westernization). They've spent the 37 years since the Grand Mosque seizure radically empowering the extreme religious conservatives and bankrolling Wahhabi expansion overseas. It helped them avoid additional internal conflict by exporting their problem children, but when the money dries up, the devil's bargain is going to come to an end with it.

The reforms the Saudis need to make are too great, and they'd disrupt too many aspects of their economy at once. And that's before you include the religious opposition into the mix. Had they started years ago, and attempted to curtail some of the religious conservative's power early on, they might have been able to ride things out. As it is now, it's going to be a very bloody crash in every sense of the word.

</comment><comment><USER7> Saudi Arabia is a medieval country. They have far greater problems than vanishing jobs and a one-sided economy. Its really a disgrace to humankind. Revolution now, please.

[https://en.wikipedia.org/wiki/Human_rights_in_Saudi_Arabia](https://en.wikipedia.org/wiki/Human_rights_in_Saudi_Arabia)

<comment><USER7> Oh right and its an ally of the western world... Unacceptable.

<comment><USER8> Frankly the cold war was basically just a continuation of the great game, with some of the players changing seats.

"History may not repeated, but it sure do rhyme."

</comment></comment></comment><comment><USER9> With the NYT, WSJ, Brookings, Economist and virtually every prognosticator of the punditry classes forecasting dark times for the Kingdom, I'm sensing a crowded trade and beginning to look for contrarian, optimistic predictions...

<comment><USER10> Good luck. I know of many many Iranian programmers. Never seen a Saudi.

<comment><USER11> Saudi programmer here. I can count 4 immediate cousins who are programmers, from the top of my head; not to mention a number of my high school classmates, a few friends from college, and others that I've met here and there. The webdev team at my previous job was all Saudis; there were even girls in the team. Absence of evidence is not an evidence of absence.

</comment></comment></comment><comment><USER12> Planet Money did a recent podcast about the situation [http://www.npr.org/sections/money/2016/02/03/465476188/episo...](http://www.npr.org/sections/money/2016/02/03/465476188/episode-681-the- oil-kingdom)

</comment><comment><USER13> I agree with how The Atlantic took this topic step further[1], which was posted on HN earlier[2].

[1] [http://www.theatlantic.com/international/archive/2016/02/sau...](http://www.theatlantic.com/international/archive/2016/02/saudi- arabia-collapse/463212/)

[2] [https://news.ycombinator.com/item?id=11143588](https://news.ycombinator.com/item?id=11143588)

</comment><comment><USER14> > 70% of the population is under 30

I don't see this ending well, there is no way this leads to a sustainable balanced system.

<comment><USER15> It gets worse,

>90 percent of government revenues are from oil; 70 percent of working Saudis are employed by the government

I don't think they've worked out the problem of stable succession either, given that every change in King has been from a brother to another[0], rather than to a son.

[0]: [https://en.wikipedia.org/wiki/King_of_Saudi_Arabia#Kings_of_...](https://en.wikipedia.org/wiki/King_of_Saudi_Arabia#Kings_of_Saudi_Arabia_.281932.E2.80.93present.29)

<comment><USER16> A possible fix is to start investing, but it may be too late. If I remember correctly I think investing for profit is a gray area in Islam, but Kuwait did it and if I remember correctly they use to have more returns from their investments then they did on oil and paid every citizen a base salary from it (until Saddam invaded and they had to cash out).

<comment><USER8> Best i recall, there is some issues with lending and interest.

After all ol' Muhammad was a merchant by trade...

<comment><USER17> Trade and investing is permissible in Islam. However interest and derivative financial instruments are strictly prohibited for various reasons, one of which is trying to avoid "renters' economy.

</comment></comment></comment></comment></comment><comment><USER18> Inevitable. But hardly surprising.

I(I'm from India) have some cousins working there to make a living. From everything I've heard, I get a feeling there is hardly any effort to build anything. No universties, and even those that exist run at the expense of people from other countries. There is crazy dole out of free cash, start from the king to the citizen.

The royal family from what I've heard literally wants everything government. The main king Ibn Saud had some I guess 10's of wives, from whom he fathered 100's of children, who now have reproduced to 1000's of grandchildren. Since not every one can be a king, you have to distribute government positions among the progeny of Ibn Saud, to keep people from dissenting and getting too ambitious to disrupt the line of succession. Apart from that from what I've heard, they also award prime contract, licenses and projects to their own family. So basically every thing stays and is designed to benefit only one family.

All this in a major tribal society, with heavy influence of the clerics. So they closely intermarry their own with the clerics and powerful tribes. Its basically a syndicate.

But they also realize that they can't do this forever. So they keep throwing some token pennies at their people. Basically building a welfare state.

There is no attempt to build self capabilities of any kind. They've tried and failed with a policy called 'Saudization'. To reduce the dependence on foreign nationals, they've tried everything. But people have so much dependence on free cash, they hardly feel the need to work. Lack of productivity(putting it mildly) among Saudi nationals or even a lack of desire to work, has been a source of jokes for decades.

Here is a hint to people in US. Look at a nation where there is "Universal Basic Income", or all those freebies and welfare benefit your guys ask for. Do you want your country, which is an example for remainder of the world for progress to turn into a nation like this?

<comment><USER19> > No universities

You have KAUST there, which is a decent place.

</comment></comment><comment><USER20> Saudi Arabia is one giant welfare state of ISIS sympathizers where they have had no incentive to innovate.

</comment><comment><USER21> Sounds like it was an interesting social experiment with all that money over several decades.

"70 percent of working Saudis are employed by the government; and even the private sector remains heavily dependent on government spending."

</comment><comment><USER22> This seems like a non-sequitur. A Saudi crisis due to cheap oil, but cheap oil is a result of increased Saudi oil production, to squash American and other shale extractors…?

<comment><USER23> Cheap oil is the result of many factors. America and other new production is one of them. Saudi response to that price drop led to further price drops. It's looking more and more like the Saudi plan will end up backfiring, as they can only bankroll the losses for so long.

<comment><USER24> And of course the losses cause just more oil production, as they turned OPEC into a zero-sum game where nobody trusts anybody else.

No good stopping your production and eating the massive, massive loss when your "partner" will ramp up and get your share.

</comment></comment></comment><comment><USER25> Man, if this is happening right now whilst the world demand for oil is high, what's going to happen to them when demand is lessened due to new technology?

<comment><USER26> When oil demand is low, they have to get into a new market like renewable energy. Solar, wind, water turbine, geothermic etc.

They have to invent the IP, and sell the equipment, and use it in their own nation to sell the electricity or batteries for money.

It takes a different business plan than oil, but they have to adapt to it sooner or later.

<comment><USER27> It is difficult to export electricity, (renewable or not) due to transmission infrastructure costs and losses.

<comment><USER28> Wouldn't reducing the transmission losses be worth them putting serious R&D effort/$$$ into?

<comment><USER25> Transmission lines to the USA from Saudi Arabia - is that even feasible?

<comment><USER28> Technically... probably possible. Feasible... that would be the R&D required. :D

Undersea cables are run for comms. So, super-massive-XXL sized superconductor versions of that...? ;)

</comment></comment></comment></comment></comment></comment><comment><USER29> Perhaps this will spell the end of the Saudi drift scene [1][2], which is ridiculous anyway.

[1][https://en.wikipedia.org/wiki/Tafheet](https://en.wikipedia.org/wiki/Tafheet)

[2][https://youtu.be/6yPIBKOQnTI](https://youtu.be/6yPIBKOQnTI)

</comment><comment><USER30> it's like seeing the same situation in all developing nations but not as bad as Saudi Arabia.

We no longer have any guarantees that our parents had. We no longer have the resources or lack of debt from our previous generation of careless expenditure.

In lot of ways millenials are fucked, but looks like more so for countries that put all their eggs in one basket.

<comment><USER31> There's a modern Sa'udi proverb that I think sums up their situation: "My father rode a camel; I drive a car; my son flies an airplane; my grandson will ride a camel." Nobody can match a Gulf Arab for sheer fatalism.

<comment><USER32> Sounds like a commandeered/re-jigged version of a quote attributed to Râshid bin Sa`îd Âl Makṫûm[1]:

"My grandfather rode a camel, my father rode a camel, I drive a Mercedes, my son drives a Land Rover, his son will drive a Land Rover, but his son will ride a camel."

So it would appear that amongst their other concerns, the Saudis also need to start producing their own fatalistic proverbs, rather than importing them from Dubai.

[1] [https://en.wikipedia.org/wiki/Rashid_bin_Saeed_Al_Maktoum](https://en.wikipedia.org/wiki/Rashid_bin_Saeed_Al_Maktoum)

</comment></comment></comment><comment><USER33> Sounds like Alaska in the near future.</comment>


Debunking the Myth of China's AI Superiority - <AUTHOR> https://www.eetimes.com/debunking-the-myth-of-chinas-ai-superiority/ <comment><AUTHOR> _A common narrative on China, prevalent in the United States, often says that China's top-down, monolithic innovation policy has led to economic success. The report calls this a "myth." Ernst argues that things are never so simple nor so homogeneous in China. The report quotes Harvard's Mark Wu: "What makes China complicated is that, while the Party-state holds vast control levers, it allows market forces to play out in huge swaths of the economy."_</comment>


Self-taught foreign language learners: How'd you do it? - <AUTHOR> I'm teaching myself using a combination of online tools. If you have been successful with this, what do you recommend? <comment><USER2> Subtitled movies and books and a dictionary

<comment><AUTHOR> I'm doing something similar. How long did it take to feel competent?

<comment><USER2> Sorry for late answer I actually learned English this way and I think that there's no such thing as being competent but more like being comfortable, it took me couple years to be able to pick up books like The Great Gatsby, Great Expectations and read them without needing a dictionary you may take less time it really depends on how much energy and dedication you put into it.</comment></comment></comment>


The Real Computer Revolution Hasn't Happened Yet (Alan Kay, 2007) - <AUTHOR> http://www.vpri.org/pdf/m2007007a_revolution.pdf

<comment><USER2> Thank God for Alan Kay. When I get depressed with the state of the industry, with the twitter mashup get-rich-quick schemes and the lack of any interest in working hard on the hard problems, it helps to know that he's around and leading the charge against that tsunami of frivolity.

<comment><USER3> Indeed ... but are he and the VPRI getting anywhere?

I don't know; by an accident of history I'm a Lisper, not a Smalltalker, so I'm not following them closely. But I don't get an impression of serious focus or progress.

Please correct me if I'm wrong; I sure would like to be, and I'm certainly finding a lot of the ideas they're throwing out to be extremely useful (or at least fascinating). E.g. generate your TCP/IP stack from the RFCs....

<comment><AUTHOR> I spend some time on their page today and another fascinating subject are active essays: <http://www.vpri.org/pdf/tr2009002_active_essays.pdf>

Basically, it's about adding runable and editable code directly into documents, one could say literate programming on steroids. Imagine for instance an article explaining an algorithm with embedded code which you could run and edit to really comprehend it.

<comment><USER3> Literate programming is a neat idea, and in the long term will probably be very valuable (or else we'll live in a Vernor Venge like dystopia of eons old cruft), but for now I'm not sure it's generally useful.

If your program is at all a serious work in progress, you're likely getting into the "too many comments that violate Don't Repeat Yourself" land.</comment></comment></comment></comment>