That is a feature, not a problem.

There are multiple programs out there to restart demon processes, if needed, with varying amounts of notifications to the admin, and varying interfaces. You pick which works best for you. An embedded appliance may need a 'restart at all costs, write a log and forget about it' program. You may want your restart program to email you, while someone else may prefer a web interface to check status. Maybe some programs should only be restarted in specific circumstances.

The Unix way is not to try to be everything to everybody, but to pick a specific function and do it really well, in a way that lets others do the same thing in a different way if they find the need to do so.

(I'll admit the biggest red flag to me about Systemd is binary logs - that prevents many useful things, in my experience.)

Designing algorithms that play well in a SMP environment under heavy loads is not easy. It isn't just a matter of locking within the protocol stack... contention between cpus can get completely out of control even from small 6-instruction locking windows. And it isn't just the TCP stack which needs be contention-free. The *entire* packet path from the hardware all the way through to the system calls made by userland have to be contention-free. Plus the scheduler has to be able to optimize the data flow to reduce unnecessary cache mastership changes.

It's fun, but so many kernel subsystems are involved that it takes a very long time to get it right. And there are only a handful of kernel programmers in the entire world capable of doing it.

-Matt

D'oh. Sorry, yeah, my bad fingers. VMS, not VAX.

VAX was already on 64-bit for ages when Linux was still in it's earliest versions. It's not going 'x86'. It's going 'x86-64', which didn't exist when Itanium was created. IA-64 was Intel's vision of the future - a complete overhaul of the instruction set. It bombed, but AMD64 wasn't written until several years later - and AMD does nice chips, but they don't really compete in that segment. (Or they didn't in 2001, at least.) It made perfect sense to port to what was supposed to be the new enterprise-class processor, instead of porting to an outdated desktop-class processor.

Linux on x86 can do lots of things, and is a very good system for many situations. If you need big iron (and the capabilities it provides - things like being able to upgrade or replace CPUs on running machines without downtime), VAX is better. In many cases you don't actually need big iron - a cluster of Linux boxes will do just fine. But when you need it, nothing else will do.

Exactly: I'm sure there are tons of custom apps written for VMS in banks, insurance companies, railroads, etc. These are places where 'if it works, don't break it' rules, and VMS is working, and has worked for decades. Being able to buy support and replace hardware is valuable to them, and I wouldn't switch platforms in their place unless there was no other option.

In the 80's it was well known that the CIA was monitoring the USENET. Apparently there was a list of keywords that they searched for that became well known, so we used them all the time. We had it on good authority that the CIA had become amused by our antics. It probably relieved the boredom.

-Matt

It's hilarious watching people argue over a topic that has already been shown to be a non-issue. The EIA (US) and German statistics show that, in aggregate, wind-energy sources produce a relatively steady amount of power. Individual turbines and even whole wind farms might not be deterministic, but all the wind farms taken together... are.

-Matt

BBEdit gets a fair amount of use as well. Some versions of xcode will even emulate BBEdit commands, if you set the right option. (And may have the option to directly substitute BBEdit as the main text editor.)

But I get your point: If you are writing in Obj-C, you are probably using xcode, because you are almost certainly developing for either Mac or iOS, and that is where you need to be.

Except you can decode the salt trivially if you took a cab ride that happens to be in the data set and you recorded the license and medallion number. At which point the salt is useless.

-Matt

Efficiency is a big selling point in refrigerators; one of the first things people will look at. (And it will be posted very obviously on every one in the store.) Cable boxes... Not so much. I’m not sure what the big selling points on them are - probably how easily it is for the cable company to monitor their usage.

Electric water heaters are probably big users in houses that have them - but I'm not sure that's even a majority of houses in the USA; gas-powered heaters are common, and more efficient.

And... that's it? What did SMART say? Did you actually wear the SSDs out as-per the wear indicator? Or did you hit a bug in the samsung controller before the wear-indicator maxed out?

To be fair, the precise situation you describe, particularly if you did not retune the RAID-6 setup or the mysql server, and if the server was fsync()ing on every transaction (instead of e.g. syncing on a fixed time-frame as postgres can be programmed to do)... that could result in el-cheapo samsungs not being able to do any write-combining and cause a 256:1 write-amplication of the data.

With proper tuning the write-amplication could easily be reduced to 4:1 and you would probably be able to run the server with SSDs. Maybe use Intel or Crucial though, and not Samsung. It isn't just the controller that matters... just using stock firmware doesn't really net you a good, robust SSD and there aren't too many real vendors who work on the firmware vs just OEM whatever was supplied with the controller. Intel is probably one of the better ones. They actually fix bugs, as does Crucial. Samsung... I dunno.

-Matt

Yes, but it's a well-known problem. Pretty much the only thing that will write inefficiently to a SSD (i.e. cause a huge amount of write amplification) is going to be a database whos records are updated (effectively) randomly. And that's pretty much it. Nearly all other access patterns through a modern filesystem will be relatively SSD-efficient. (keyword: modern filesystem).

In the past various issues could cause excessive write amplification. For example, filesystems in partitions that weren't 4K-aligned, filesystems using a too-small a block size, less efficient write-combining algorithms in earlier SSD firmwares. All of those issues, on a modern system, have basically been solved.

-Matt

I have around 30 ranging from 40G to 512G, all of them are still intact including the original Intel 40G SSDs I bought way at the beginning of the SSD era. Nominal linux/bsd use cases, workstation-level paging, some modest-but-well-managed SSD-as-a-HDD-cache use cases. So far wearout rate is far lower than originally anticipated.

I'm not surprised that some people complain about wear-out problems, it depends heavily on the environment and use cases and people who are heavy users who are not cognizant of how they are using their SSDs could easily get into trouble.

For the typical consumer however, the SSD will easily outlast the machine. Even for a pro-sumer doing heavy video editing. Which, strangely enough, means that fewer PCs get sold because many consumers use failed or failing HDDs as an excuse to buy a new machine, and that is no longer the case if a SSD has been stuffed into it.

A more pertinent question is what the unpowered shelf-life for typical SSDs is. I don't know anyone who's done good tests (storing a SSD in a hot area unpowered to simulate a longer shelf time). Flash has historically been rated for 10-years data retention but as the technology gets better it should presumably be possible to retrieve the data after a long period on a freshly written (only a few erase cycles) SSD. HDDs which have been operational for a time have horrible unpowered shelf lives... a bit unclear why, but any HDD I've ever put on the shelf (for 6-12 months) that I try to put back into a machine will typically spin-up, but then fail within a few months after that.

-Matt

Never played the game. Didn't even know the concept was discussed in it.

And, on a relative scale, yes it's not hard. It's certainly far easier than sending a ship to trade with someone that far away. In fact, nearly all of the problems of interstellar travel go away in this case - the basic fact is that not having to slow down when you get there (and not caring about the safety of any occupants in the vehicle) makes the issue massively easier. You don't have to worry about fuel, or shielding, or long-term biological maintenance. Just accelerate it up to speed and have a few final maneuvering thrusters on an automatic system.

Of course, if you are traveling around you've solved those problems, and can if you wish launch from within your target's solar system. Which makes targeting much easier, though you may give yourself away as you get the weapon up to speed.

On the other hand, hiding isn't as hard as you might think, especially if life (but not sentient life) is moderately common. Most of it even makes economic sense: Keep your transmissions low powered and focused so there isn't much leakage, and keep the atmosphere fairly clean. That will make it nearly impossible to tell an 'inhabited' system from a 'life-bearing' system from any distance.

Of course any aliens could be proactive and be striking at any life-bearing system, although that's a lot of wasted effort. Still, even then if we were to move into space-based colonies and asteroids we could hide fairly effectively. (Again, communication would be the biggest leaker, but economics and the square cubed law help the hider out.)

This is a reasonable fear - and the problem is unless you are sure the universe isn't that competitive, it actually makes sense to assume it is. Because it's not hard to build a relativistic weapon your target would never see coming, and would wipe them out with one hit. (And we wouldn't see much evidence of them out there, even if they were fairly common - they look like any other floating rock, really.)

So the moment you announce yourself you could become a target for an unknown assailant who will kill you before you know they are there. Run the odds on whether you want to chance announcing yourself then, and realize everyone else who might be out there is doing the same...