While this looks like a perfectly reasonable language, I'm a bit weary of this sort of bragging about line counts. I could do the same thing, it would look roughly like:
ssh pi2.local 'while :; do pitemp=`ssh pi.local get_temp`; mytemp=`get_temp`; if [ abs($((mytemp - pitemp)) -gt 2 ]; then echo "Temperature on pi is $mytemp and on pi2 $mytemp. "'
(abs and get_temp are up to the person to have the functions).

Talk about the syntax being nicer, but lines of code is no big deal in this particular case. It has a nice and non-ugly 'run this on another host' syntax and automatically takes care of the communication channels in a reasonable fashion with a low amount of fuss. Leave it at that.

Also, the trap is that any term that gets adopted will *become* yet another idiotic marketing term.

Any phrase attracting buzz is doomed to become a meaningless marketing term abused by companies with their agendas to be relevant.

I particularly dislike the phrase 'internet of things', but I know I'll dislike any term that sees common adoption while the media/marketers have an interest in the field until that interest dies down and it no longer becomes fashionable for companies to shoehorn it into their message.

For contrast, I had a minimum mortgage payment of 850/month on a 3,000 square foot house, had enough extra to pay it all off in 8 years. It's a fair point that $66k/yr in most areas easily beats $100k/year in SV. That's one thing if you really *want* to live in Silicon Valley, but if you move there because of a better job opportunity and didn't particularly care about being in SV specifically, you are probably making the wrong move.

Basically, I've encountered two classes of H1-Bs:
-Folks who are exceedingly good at what they do and are sought out by name. They are by no means cheaper, but a company has to do H1-B to get them.

-Folks who are cheaper and held hostage to their circumstances.

I think across the industry the latter is at least somewhat more common (it's the simplest explanation for the high volume of H1-B requests from specific companies, it's unlikely one company would need the former case by the hundreds). However this situation results in some reactions that are highly offensive to those in the first category.

I was $55k right out of college 13 years ago. Those were, frankly, the easy jobs to get too.

After reading through the paper a bit, it seems interesting, but perhaps a bit overblown. It seemed to have a lot of work to understand the very specific problem domain before this could be applied. It's more like a methodology *enabled* expert engineers to do optimization, not that it did optimization *instead of* expert engineers.

It's also a field with a lot of solid technical high level algorithms, so there was a pretty good space to map things to. Basically it was identifying what inscrutable code was doing as it relates to well known algorithms, enabling them to start fresh to apply the best practice today of said algorithm. If you are not in this sort of space, the strategy doesn't really have a way to help very much.

Incidentally, it's (probably) not in this case that the code was sub-optimal, just mis-optimized. Whether it's something like code written before AVX2 existed, now adding AVX2 codepath, or scenarios with two algorithms that end the same way that use different operations where a choice was made based on chips that could do one of those faster, and newer chips started getting faster the other way.

If there is a substantial removal, it's hard to imagine that there *wouldn't* be roads that provide direct access to homes, or sole access to some homes in the middle. If a road *can* have a house or business built along it, a house or business will likely end up connected to it. Freeways are the only sorts of roads that wouldn't suffer this phenomenon, but even then there are likely to be roads that are only connected to the larger road network by way of the freeway.

Only a few use 14nm today. It's still relatively scarce.

Also, a company that no longer had a fab did a proof of concept in a lab. This is not what the headline suggests. It's nice to know that we have a proven hypothetical to get down to 7, but the practical side of things has a tenuous relation to research.

I think you can be more strong on this point. The reality is that this *is* the mainstream. 'The Cloud' work is important, but more than important, the people doing it are *louder* than everyone else and the media coverage high since it is novel, but mainstream is remarkably little changed over the last several years.

That is the facet I find concerning, 'RTM is no big deal' statement is bad because it *should* be a big deal.

Maybe they can juggle LTS and non-LTS effectively, but they have every risk of getting too caught up in the enthusiast perspective and pissing off a lot of their users. I know a fair number of people pissed that their google apps change drastically on a whim on their phones, and it seems MS may jump to that model. That said, the pissed off users don't really have anywhere to go. The developers rule the roost nowadays and all companies are enabling new and shiny and changing and no one is being pushed to drive for a stable experience.

It would be bad form to reset the password when anyone clicked 'reset this accounts password' anyway. So until the link is followed, no action should be taken with regard to the account password anyway. This way a malicious person can't just denial of service a valid account by clicking 'reset my password'.

This means if an attacker is able to intercept your SMTP, they could still hijack your account through requesting a password reset at will, so it's not perfect, and yes some 2 factor authentication would be nice *if* it were an important site. Account creation needn't have this particular hole, just password reset.

If you didn't want to SMS, you could use TOTP (e.g. google authenticator is one implementation, but not the only one). Though either way that's something to potentially lose so it would be a suggestion option for those increasing security.

The UUID is discarded on first login. Additionally, the UUID is useless without the password/credentials.

The idea is that the user set his password via (presumably) secure https. The purpose of the random hash is so that you provide the legitimate email user a transient secret that must be used *in conjunction* with the password they had chosen (or some session cookie sent via https to avoid making them log in twice when clicking on the email).

So here the password is to authenticate that the original person that accesses the site, the hash authenticates a valid email account. Both together are required to verify the account is valid. This way someone intercepting SMTP doesn't get access to hijack account and someone without a valid email can't get an account activated.

eth0 being renamed to biosdevname and then 'consistent' device naming happened outside of systemd per se. It's one of the various questionable things that came along at about the same time as systemd, and systemd gets the blame for *all* of them, when it only brought some of it. E.g. complaining about binary logs, you can aim that square at systemd. Most of the other prominent rants commonly fired at systemd are either dbus, networkmanager, udev, or something else in reality.

The network device naming is one facet where they can't win. The ethX has problems, and so does the current state of consistent device naming (notably that if an adapter veers off into being enumerated by pci, it's probably a lost cause in all but the most extremely homogenous environment and doing those names is just causing more trouble than helping)

I agree that Torvalds isn't the authoritative god of all that makes up a distribution and as such his opinion is one to be considered, but no the only one.

Also he speaks to the biggest fundamental controversy, the log strategy/format. I agree with Torvalds, that the capabilities of systemd are interesting, but I personally find the bathwater that comes with it troublesome enough to not want it. That and how they engage with the community at times. A lot of the other gripes about systemd are more implementation mistakes that are unintended and often addresed, but this part is very explicitly intentional and counter arguments have been dismissed out of hand.