I didn't say it wasn't dishonest (or unethical, for that matter) at all, just that it was less so. The important thing is that obviously self-contradictory arguments are easier to refute. This lawmaker's stupidity has eclipsed his dishonesty, and that's good (for the rest of us).
The religious view was in the part of the law that you reduced to ellipses:
(iii) The standards in science shall be based in core existing disciplines of biology, chemistry, and physics; incorporate grade-level mathematics and be referenced to the mathematics standards; focus on academic and scientific knowledge rather than scientific processes; and prohibit political or religious interpretation of scientific facts in favor of another.
The essential thesis of creationism (and "Intelligent Design") is that the Scientific Method is bunk because "God did it." This law comes very close to prohibiting teaching the Scientific Method (i.e., "scientific processes"). Connecting the dots is left as an exercise to the reader.
On the bright side, framing the debate in those terms might help convince the kind of people who would argue that we should "respect all sides of the issue" (or some politically-correct BS like that) that these anti-scientific ideas really don't belong in science class after all. I think the lawmaker did us a favor and I'm optimistic that his plans will backfire.
I've argued many times before that the problem with "Intelligent Design" is not that whether it's "true" or not, but rather that it's not science because it ignores the Scientific Method and thus does not belong in a science class. I'm glad that this lawmaker, at least, is willing to address that argument directly instead of obfuscating.
He's still wrong, of course, but at least he's less intellectually dishonest than the average creationist. That's convenient, since it makes his position -- which is that Ohio should prohibit schools from teaching science entirely (since science is the Scientific Method) -- easier to both understand and oppose.
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.
Not really, both would work, but fewer people are good at declarative which means it's bad for system tools.
Most systemd units are about 5-10 lines long. It is pretty hard to mess that up. That's the point.
I'm arguing flexible design over monolithic when it comes to something like init.
Systemd, the monolithic binary that links all the way up to GUI layers. You'll need to reboot for just about every software update.
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
Try a bicycle. It's a marvellous machine, probably the most efficient machine that anyone can go out and buy. When you ride a bicycle for utility you're not just riding to get exercise for the sake of exercise, you're getting useful transport out of it, too. In many urban settings, riding a bicycle for transportation is no slower than any other method of transport and is considerably less expensive and considerably less dangerous once you consider the risks of chronic diseases brought on by lack of exercise you'll avoid.
Even where I live (which is very uncongested traffic wise) where cycling has a time cost, I effectively get two minutes exercise for the price of one minute for every two minutes I ride since driving to work still takes half as long as cycling to work, and not only do I get great health benefits from it, I spend far less on my car by not using it all the time.
They still sell tape drives? Must be marketed toward the old geezer crowd or something.
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.
Something tells me you're also a systemd proponent.
It's about simplicity, and therefore flexibility. If
I've yet to see a standard text file editor which is able to view a text file in
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
But yes, I am a systemd proponent.
But I couldn't care less since containers and virtualization are an exercise in bloated pointlessness. Most operating systems can already run multiple processes simultaneously.
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.
Haven't seen this except in faulty scripts.
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.
9. Doesn't support minor tweaks to init script configuration like adding ionice without merging changes on every package update.
Don't know what you mean, all the files are editable, and you're not supposed to just blindly replace config with defaults.
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.
The point is, openrc (just like sysVinit) is a generic tool that doesn't make unnecessary assumptions about what you're trying to do with it and due to its scripted nature has no imaginary boundaries.
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.
I'm an aircraft mechanic but most people are not, and most people would shit a cactus if they had to pay to maintain their car to aircraft instpection and maintenance standards.
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.
Autonomous cars and trucks will have to have a comprehensive sensor suite to warn of pending failure and in some cases disable the vehicle so it can be safely towed off for repair. A conventional auto can limp to safety using manual steering and brakes. Those systems also operate even with total loss of electrical power. They are highly reliable.
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.
Since owners who are not technicians cannot competently assess system conditions, the automated systems must take away their choice and that means some control of "re-arming" the vehicles for legitimate test and diagnosis.
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.
They will also need to be EMP hard. Not because of some apocalyptic nuclear scenario which isn't going to happen, but because otherwise they will be easy kills with primitive HERF equipment, and even more so where metal bodies give way to composites and plastics which offer no grounded shielding.
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.
Healthy components are replaced BEFORE they fail. It's very expensive.
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.
From every experience I've had with systemd, I'd say that it is NOT progress. I don't want every little thing integrated in the manner systemd does.
Integrated in what way? Sure, they have a bundled suite of applications, but you can swap out journald for syslog just as you can swap out koffice for libreoffice if you run KDE. It has some dependencies like udev and dbus, but that's just a design choice.
You can't "swap out journald for syslog" you can have journald and syslog, but you can't not have journald; so you will still be just as screwed when journald goes tits up.
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
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.
In fact, it would not surprise at all if the brake itself is NEVER removed.
How is having a brake a safety feature when there is interleaved traffic crossing an intersection? If a car were to rapidly stop, it would get broadsided by another car expecting it to not stop.
I could see the brake sticking around until it is illegal to manually drive a car, however.
The question is what was wrong with OpenRC?
It's flexible enough to do just about all the useful tasks that sysV and that systemd does.
1. Doesn't support being run in a container (though this is being worked on).
2. Is slow to start up, which is important for containers.
3. The network setup scripts could use improvement.
4. It tends to leave orphaned processes lying around.
5. It doesn't care about exit status for anything.
6. It can't shut down without leaving read-only filesystemd mounted.
7. It takes quite a while to actually shut down.
8. It lacks support for service monitoring.
9. Doesn't support minor tweaks to init script configuration like adding ionice without merging changes on every package update.
OpenRC is about as good as a SysVInit gets, and it continues to improve. However, despite being around for almost a decade it has already been surpassed by SystemD in most respects. I'm glad it is out there in case I ever run a box that can't run SystemD, but I doubt I'll be using it much despite it being installed on every linux box I currently administer.