And since this is a camera passthrough, not an optical overlay, that's a glaring implementation flaw. Properly aligning the head tracking framerate, camera framerate, and rendering would let them render the virtual objects in lockstep with the physical ones (at least at speeds where motion blur isn't a significant issue; you can fake that by minimizing motion blur in the real image by using a short shutter time on the cameras).

So, they're locking out things that can brick the card (flash ROM/fuses, screw up thermal sensors) and apparently a hint of OS security (the Falcons that respond to userspace commands can no longer access physical memory, only virtual memory). The latter sounds somewhat bizarre, considering the firmware should be fully under the control of the driver, not userspace (I guess/hope?), but not unreasonable. Maybe there are software security reasons for this.

Nouveau is free to continue using its own free blobs or to switch to nvidia's. If they start adding restrictions that actively cripple useful features or are DRM nonsense, then I would start complaining, but so far it sounds like an attempt at protecting the hardware while maintaining manufacturing flexibility for nvidia. This isn't much different from devices which are fused at the factory with thermal parameters and with some units disabled; the only difference is that here firmware is involved.

NV seem to be turning friendlier towards nouveau, so I'd give them the benefit of the doubt. If they wanted to be evil, they would've just required signed firmware for the card to function at all. The fact that they're bothering to have non-secure modes and are only locking out very specific features suggests they're actively trying to play nicely with open source software.

So the people that build the system do not care about it. *plonk*

Why should it be replaceable? It is internal. You are fine as long as you can attach everything you need as some kind of backend to that interface.

Yes, some of the gcc extensions in the kernel are getting removed. On the other hand the clang compiler is getting extended to handle more gcc extensions. It already does quite a few.

Once clang builds the kernel it will most likely also build systemd:-)

Oh, come on... *ALL* init systems do IPC. That might just be a simple pipe somewhere, but that is still IPC. How do you think telinit works?

KWin (the KDE window manager) will depend on logind at the very least for wayland. ConsoleKit is dead, so anything currently using that will need to look for an replacement soon. That includes basically every DE out there.

Some might come up with a different solution, some may function without logind, some will just require logind like gnome does now. Let's wait and see how that will work out.

You are aware that logind, journald and networkd are all stand-alone daemons that just happen to integrate well with systemd-PID1 and that live in the same source code repository? You do not want them? Just disable them.

Journald is a bit of an exception here: It basically provides the logging infrastructure for the other parts of the project. So all you can do there is to have it forward the logs to syslog.

I entirely fail to see why binary logs are such a big argument, considering that syslog is fully supported. Push your stuff there, RHEL7 apparently even does that by default. You still get more information into your logs that way than you used to. So you win, independent of whether you use journalctl or cat on the files syslog creates to read them.

No, but then FreeBSD is of course free to have several init systems if they care. Traditionally they do seem to prefer a more consistent user-space developed by one team.

I do not get what you are going at with this point.

Yeap, it is getting more and more common, even on embedded hardware. There is so much software out there that is basically untested on anything but glibc that it makes sense to use that libc if you do not write everything in-house.

I used "we" exactly once and I am pretty sure there will be very few people indeed that defend the crontab syntax.

I am in no way talking about features of any replacement init. I am talking about interfaces other applications are depending on.

This may be udev, or the hostname/data/time configuration or logind or whatever else. Fact is that gnome is depending on some of these interfaces. KDE announced that they will do the same -- at the very least for wayland. I doubt that the other DEs will be far behind, especially now that ubuntu wants to move to systemd, too. These interfaces are apparently not all bad, so developers want to use them.

So if you want to run any of these applications, then you need to provide these interfaces in one way or another. This can be by either using systemd, or systemd-shim or systembsd or whatever implementation. There are quite a few to choose from at this point:-) For a new project to remove all that code and claim it is not needed is naive at best.

The features provided by the init system itself or how those are implemented is irrelevant to my point.

It is a feature to some, a misfeature for others. It definitely does not make this uselessd a viable alternative to systemd for mainstream distros.

Not at all. It is just sound development: Come up with a interface you use in your code for the functionality you are using from others. That way you can have different implementations. In this case: Push logs to /dev/null, use journald or push it to syslog. Actually it is exactly what makes this flexible and modular.

This project is indeed useless:-)

First it implements the PID1 part of systemd, cutting out things like hostname, date and time management and logind. So this does *not* ship the things that are needed to run Gnome (or soon any other desktop environment). So you need systemd anyway... or a systemd shim or systembsd or whatever to provide the functionality that is missing.

It removes journald... and with it really nice features like systemctl status whatever showing the last bit of output from that unit. That is a huge step back, especially since much of the journald code still needs to stick around: It is the "internal" logging interface used in systemd. It just feeds it on to syslog now instead of writing it to disk, something you could do with one line of configuration.

Removal of udev? You need that functionality, so again you will need to install "real" systemd or some other piece of code replacing that. Again you could just reconfigure the "real" systemd to use any alternative implementation in place of its own.

Then it advertises that it is portable. The developer apparently spend time to make this run on FreeBSD, which is nice, but has anybody in that came ever asked for that? AFAIK they are working on something like Apples launchd. Any other of the BSDs that want systemd? Not that I am aware of.

Then it is portable to other compilers but gcc. Systemd uses gcc extensions that make for more robust code (e.g. destructors for variables). Ripping that out will just lead to more bugs, especially in the error-paths. Not sure that is worth the trouble.

Finally it is portable to other libcs. That is actually somewhat nice... even though glibc is the dominant libc implementation on linux systems (that are not android:-).

Then it removes some really convenient functionality like the timer units. Do we really want to go back to the cryptic crontab syntax? If the job there is somewhat complex it will most likely start a systemd unit anyway (for the security features, resource management, the way better logging or just the better job control). PID1-systemd needs to know the time anyway, and it needs to start jobs, so why not have it start jobs based on the current time? That is definitely less code -- and probably better tested, too -- than running an extra daemon for that rather trivial job.

It also removes the support for the security frameworks... "to stick to a more clearly defined purpose, one that is agnostic of such elements". Wow, that is just plain stupid. If you want to use these frameworks, then you want to have them in use *everywhere*. That is the whole purpose of those frameworks.

I should say that Tesla's offerrings are nowhere near what my pocketbook could accomodate. Having said that, I wish nothing but good luck to them.

Dealerships are useless, blood-sucking parasites, and I won't shed a tear for them, if those massive wasters of useful oxygen will disappear from the face of the earth. Even though I've gotten the art of buying a car down pat, keeping my actual interaction with those vermin to an absolute minimum, and even if, by my own estimates, I reasonably avoid having to deal with maybe 90% of the bottom feeders a typical car buyer would be subject to, I'd still wish them to burn in flaming pits of hell.

I have to laugh at their PR spin, when they claim how dealerships are the best way to buy cars. Blah, blah, blah. I can safely safe that, having bought 3 cars in the last ten years, dealerships are always just a waste of my nerves, they add absolutely nothing of value, and only inflate the price of a car through their markups. I wouldn't actually even mind if all that having these dealerships around do would add a modest markup to the price of a car, in exchange for a little bit of service. If that was all to it, then I don't think I'd mind it at all. But that's just a small part of the problem, and I'm sure it's quite clear what I'm talking about, so enough said...

Let's just say that I'm rooting for Tesla, even though if they win it would do absolutely nothing for me directly. Indirectly, yes: not having to deal with those parasites, the next time around, would be a big plus.

Not 2^16 (Unicode already has way over 2^16 codepoints assigned). The maximum Unicode codepoint value is 1114111, which is somewhat over 2^20 (and happens to be the highest codepoint encodable in UTF-16).

$Dayjob$ hires talented interns from local scrools of higher learning, every summer. Many of them come back for a few years, as they finish up their bachelors.

Your university most likely has a few beaureaucrats in some kind of a career placement office, of sorts, that are likely have leads to local companies who have open summer internships.

A few of the best $dayjob$'s interns get a job offer, after they graduate. And all of them earn some beer money during the summer, and have something to go on their resume.

Considering that reparenting processes that double fork is tried and true unix philosophy: It would be somewhat surprising to see apachectl properly clean up after itself in your so called cleaner system. Maybe you just fail to properly recreate the problems in your trimmed down universe?

None of the init systems currently in use is conceptually very complex. In the end sysv init is actually one of the more complex ones. The others are of course different, but I would not actually call them conceptually more complex.

In fact setting up a service and then starting it is significantly simpler with systemd (and upstart and openrc) than it is with sysv init. Give it a try before complaining about it.

Hmmm... why would you? Maybe because these are fundamental issues with how sysv init works?