Fighting crime costs money. If we wanted to save money, we could just fire all the cops. It is worth it to spend $20k rehabilitating somebody who is caught committing a crime that costs society $100, because the alternative is more crimes being committed, and likely at escalating cost.

These cameras would be an incredibly beneficial investment. It is worth it simply for the ability to restore faith in the good cops who have been doing their jobs right all along. Chances are it will turn quite a few of the rotten ones into at least acceptable ones.

Agree. I have a dash cam in each of my cars and it only cost $70. Everything but the battery in those would be more than adequate for something an officer would wear. Obviously a police officer would not be tethered to a car, so I can accept that a portable unit with an all-day battery capacity would cost more, though the battery could be attached to the belt.

That was his whole point. The fact that many people think that the one is a substitute for the other indicates that there is a big problem in CS.

That said, trivial statistical problems usually don't require calculus to solve. I fully appreciate that commonly used statistical functions are rooted in calculus, and you need to understand it at some level to apply them properly. However, the mechanics of solving the problems usually do not require solving integrals/etc. To use a car analogy - I can use a speedometer without knowing what a derivative is.

I think you hit the nail on the head. Nobody cares about getting it right, they just care about getting it accepted. People know enough statistics to be dangerous.

But the same is true of almost any field. Unless you work in some kind of skunk works team, how many of your coworkers REALLY have a good grasp of the fundamentals in whatever profession you work in? Do you think the average CS major has any idea what an opcode is, or how to implement a binary adder (just in terms of theoretical gates, let alone actual circuitry)? How many cooks really appreciate how the presence and properties of water affects the temperature at which food cooks?

I'm sure even among experts, the average statistician is, well, average.

Sure you can. Just set Storage=volatile or Storage=none on journald. Then configure everything to log to syslog as you normally would. From a logging perspective it won't be any different from sysvinit. All systemd does normally is take stdout from processes it manages and direct it to the journal. Sysvinit would just discard this output anyway - the only way anything ends up in syslog is if some process explicitly sends it there. The only systemd process that is persistant if you're only using it for init is systemd itself, and it can output to syslog.

They maintain them. I have no idea why kdebase lumps so much stuff together, or why binutils is such a hodge-podge. But, you don't have to use all of it. Just about any distro using udev fetches the systemd tarball, builds udev, and ditches the rest if they aren't using systemd.

But, I'd certainly prefer split sources as well.

If your goal is to backup data in bulk offline you will want to use 3TB drives, not 6/8/etc. There is always a sweet spot and right now 3TB are it. I'm sure that in time the 8TB drives will be the better deal, but at the moment you're paying a premium so I wouldn't get an 8TB drive unless the application limited the number of SATA ports you could use.

Compression at least is a wash - anything you can do to compress data on a tape can be done to compress data on a hard drive.

No question that modern LTO can stream quickly though.

Most systemd units are about 5-10 lines long. It is pretty hard to mess that up. That's the point.

ldd /usr/lib/systemd/systemd
                linux-vdso.so.1 (0x00007fff69a67000)
                libpam.so.0 => /lib64/libpam.so.0 (0x00007fbd1ece2000)
                libcap.so.2 => /lib64/libcap.so.2 (0x00007fbd1eadc000)
                libkmod.so.2 => /lib64/libkmod.so.2 (0x00007fbd1e8ca000)
                libseccomp.so.2 => /usr/lib64/libseccomp.so.2 (0x00007fbd1e6b4000)
                librt.so.1 => /lib64/librt.so.1 (0x00007fbd1e4ac000)
                libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fbd1e28d000)
                libc.so.6 => /lib64/libc.so.6 (0x00007fbd1dee1000)
                libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/libgcc_s.so.1 (0x00007fbd1dcca000) /lib64/ld-linux-x86-64.so.2 (0x00007fbd1eeef000)
                libdl.so.2 => /lib64/libdl.so.2 (0x00007fbd1dac6000)
                libattr.so.1 => /lib64/libattr.so.1 (0x00007fbd1d8c1000)
                libz.so.1 => /lib64/libz.so.1 (0x00007fbd1d6ad000)

Care to try again?

I've never seen an update that REQUIRED a reboot due to the use of systemd. Sure, if you're upgrading systemd or something it links to like libz and you want to use the most recent version, then you would need to reboot. But, it isn't like it just stops working in the meantime.

Systemd isn't monolithic either. On my distro it consists of 41 binaries (not counting stuff in /usr/lib and such). It isn't like networkd is built into PID 1.

They're cost effective if you're storing a LOT of data and you don't need to regularly access it.

An LTO-6 drive costs about $2500, and it stores 2.5TB of data on a $50 tape. That is about half the price of a comparable hard drive. If you have more than 100TB of data to store then tape becomes cheaper (that is, the savings for the tapes exceeds the cost of the drive). Tape is also a bit less fragile during transport/etc, and likely more reliable than optical media unless you buy the expensive stuff (which certainly isn't any cheaper than tape).

Doing anything with those kinds of data volumes is always going to be slow, whether you're talking drives/tapes/etc. So, if you need rapid recovery or have a lot of turnover then strategies like replication to a live remote site is going to be necessary, and tape will never give you a great recovery time. It is better for retention for "just in case" scenarios or legal reasons - where recovery time isn't as important as just having the ability to recover at all.

I've yet to see a standard text file editor which is able to view a text file in /etc without the aid of a very non-standard filesystem driver. There isn't anything simple about how computers work - there are failure mode around every corner. Using a non-text-file format is just another design decision.

Besides, when your hard drive crashes it is pretty hard to read the text files on it. On the other hand, when the configuration is stored in a replicated database, your cluster can keep on chugging along.

Even most admins who love text files in /etc stick them in non-text repositories like git just to manage things.

But yes, I am a systemd proponent. :) You'll be happy that it tends to use text files (and not turing-complete script files) to store all of its configuration. In the preferred mode of use it does store logs in a binary format, but I don't see too may people needing to use arbitrary tools to edit their logs (not that it isn't trivial to dump them into text). Like everything else, that was a design decision as well.

Containers have nothing to do with an inability to multitask. They're about, well, containing changes. That is, if I update glibc I don't have to worry about testing 47 different services on the host to ensure they all work before walking away. Instead I only have to test one, since that glibc is private to a single service. They do consume more RAM, of course, since less is shared in memory. That is the tradeoff.

The whole point of a robust design is that it makes errors harder to commit, and handles them better. If nobody wrote bad code we wouldn't need process memory isolation either.

That is the problem - the files are editable. That means that every time you update a package you have to re-merge the stock scripts with all your changes. With a systemd drop-in you can override a configuration setting without editing any file owned by a package.

You can run scripts from a systemd unit if you need to, but the point is that 95% of the time you don't have to.

You're basically arguing about the merits of procedural programming over declarative programming. Sure, there are things you can do with the one that you can't do with the other (setting aside the ability to do scripting from a unit file). The thing is, 95% of the time, the things you tend to do with procedural programming is introduce mistakes that would be trivially avoided otherwise.

But, to each his own. OpenRC isn't going away anytime soon.

Not necessarily. There would be economies of scale. There are also a lot of practices in aircraft maintenance that could be streamlined, like having central records so that every mechanic isn't responsible for basically double-checking everything every mechanic beforehand has done. It shouldn't be any more expensive than just dealer-maintaining your car over its lifetime, which is WAY cheaper than a typical aircraft maintenance regimen.

I'm sure there will need to be a differing set of standards for redundancy/etc for reliable autonomous vehicles, but I'm not convinced that it would be over-the-top. How often do cars have major electrical failures? I imagine that it happens less often than on your typical 40 year old Cessna, even if the results are worse. You could also have dual electrical systems and such, especially for critical components. The car really just needs to be able to coast to safety - this isn't a plane where no radios in IFR is a potentially deadly situation.

I do agree with this. However, in many cases the cars could also drive themselves in for PM well before they are crippled, which would be a major convenience. People would be far more likely to rent and share cars as well when they can be at your door in 2 minutes.

I don't buy this. It is a bit like saying that conventional cars need to be hardened against 50 cal sniper rifles, since one shot to the driver could cause a pile-up. Shooting an HERF at an autonomous vehicle is homicide. So is firing on an airliner during its takeoff roll - I'm sure the same sniper rifle would cause a lot of havoc there. The solutions to these problems don't involve systems engineering, though I'm all for reasonable levels of robustness.

Actually, on airliners many components are flown until failure when they aren't critical for safety and there is sufficient redundancy. This is part of what makes them more reliable than general aviation - they aren't constantly doing things like servicing all the magnetos (we had a fatal helicopter crash nearby due to improper maintenance and resulting dual engine failure a number of years back).

I do get what you're saying though. If we really want vehicle safety to rise to the level of flight safety, then you can't have people doing their own oil changes without the equivalent of an A&P.

You don't have to use journald - that is the point. Or at least you can set it to non-persistant storage so it doesn't exist outside of /run, and the only logs you look at after a reboot are the ones stored by your syslog.

The coordination between cars will have to have a default-safe mode of operation. That is, the car won't go someplace until it is sure it is safe to go there, and it will always have a safe exit-to-stop route that is coordinated with all other nearby vehicles.

So, suppose my car is parked on the side of the road. It gets a reservation that allows it to be in a box that moves down the road at a certain rate for a certain distance. with an exit to a point where it is stopped at every point along that route. If the car doesn't get a new reservation to continue on its route, then it will take the last exit reservation to get off the road safely. It won't get a reservation until the supervisor has coordinated reservations with all other local cars.

That is basically how aircraft traffic control works. Planes get clearances, and that clearance gives them conflict-free flight for a considerable distance. If communications is lost, the behavior of all planes is still specified, and should be reasonably conflict-free. Of course, that system is manual, and not completely rigorous. Planes are also hard to park when everything goes wrong.

I'm sure it won't be perfect, but there is no reason that cars couldn't be made as safe as flying. That would include standardized maintenance, procedures for all contingencies, etc.