Google doesn't innovate? The software on the new Pixel 3 is nothing short of amazing from spam call answering to night mode photography. And it is all getting backported to earlier Pixel models as well.
There's a Youtube channel called something like 'AI Channel' that has relevant talks. LeCun did a big one a few months ago. Hinton has had at least one Google Talk.
A ton. I was involved in the successful opposition against a wind farm project in Canada that was proposed for just north of a major internationally protected migratory bird habitat[1]. Habitat destruction is just a big an environmental problem, and actually probably bigger, than climate change in North America. We are down to less than ten percent of native grasslands remaining in our continent which is the biggest slow-motion environmental disaster that doesn't get talked about much.
What's the point of renewable energy if not to help protect natural areas like the ones being proposed for development?
These huge renewable projects do have major ecological impact, why lie about it? Due to low power generation density they take up a lot of space compared to fossil fuel/nuclear plants and that's not including the large amount of power lines that have to be run to all these new facilities. There are well known negative ecological impacts from the solar farms in this area that others have pointed out.
Just because a desert or prairie ecosystem isn't as obvious a conservation target as a forest doesn't mean they are not valuable ecosystems that shouldn't be protected from development.
There's no free lunch in energy generation, every form of it has some ecological drawback. Look at this virgin forest that Georgetown University wants to cut down to put a solar facility up. How is this a net positive for the environment?
Well the alternative to more renewables is, realistically, more coal and gas. I think that covering up one or two percent of even the most valuable biomes with solar panels is no where near as destructive as climate change.
California already has some of the lowest per capita energy consumption in the US [1]. A good part of this is due to the mild climate where most Californians live, but some part of it choices people have made, like the widespread adoption of residential PV in cooling load dominated inland areas.
EVs are also taking hold faster in CA due to their better economics and broader cultural appeal in CA.
All these trends will lower the per capita energy consumption further without negatively affecting lifestyles.
While it seems like a bad idea to cut down a forest to replace it with a solar farm, that's not virgin forest. As cited by the article, the land has been timbered before. There is almost no virgin forest left in the eastern US at this point.
I agree, but will never ever comment on this (in a thread, where I'm downvoted).
The worst is being downvoted for the dissemination of fact, ideally supported by sources.
Some lesser smart members of this fine forum seem to even downvote comments like this if they dare to go against the party line.
Then again, and as the moderators outline correctly, it's often auto-corrective and I, for one, upvote comments, which are unfairly downvoted. No matter their merits.
Online mattresses became popular because of the multi-naming, multi-branded, high-margin existing world of mattress sales which was, and is, way scummier than online mattress sales are. Plus, how are you really going to judge a mattress by lying on it for a few minutes?
Wirecutter is owned by the NY Times and does very good reviews. You can also spend a few bucks to buy a Consumer Reports subscription for a month and access their huge testing database and years of experience.
> how are you really going to judge a mattress by lying on it for a few minutes?
When we purchased our mattress ( a Vi-Spring ) the store only accepted our order after we had lain on a matching configuration in-store for 20 mins. Or was it 30?
If felt odd lying in the middle of a shop but apparently it was the only way to enable the softness-exchange warranty. We could switch up or down one softness grade but had to find the starting grade like that.
Where were you two weeks ago! Ah, now my next 10-20 years of sleep will be bothered by knowing my mattress, which I enjoyed last night is sub-optimal for my sleeping style!
Seriously though, thank you, I'll keep that in mind for my next major purchase.
For sure, you may have very well got a good mattress at a good price. However, things you did like price-matching don't work in mattress-land because all the companies release the same mattress under different models, brands and SKU's, precisely to defeat those tools.
Online mattress sales became popular precisely because of those scummy tactics, as well as very generous return policies, where you can actually use your bed for a significant amount of time before you make a decision on it.
If I may high-jack: looking for good mattresses which will also be good in 2 years, I came to the conclusion that DIY is a good way to know what you get and save some bucks. Any recommendations?
My current plan is to have either a spring or dunlop latex base, with then 3 inches of firm dunlop and 2 inches of medium dunlop latex on top. Side sleeper (mostly)
Yes, but it's a little hard to know what to do when you go to look at their top-rated items and there are tons of negative reviews. That has been my experience recently looking at the highly rated Bluetooth receivers on Wirecutter and ranges on Consumer Reports. There aren't that many total reviews on Consumer Reports though, so maybe the complainers there are overly represented.
Apparently wirecutter will demote a product if the company won't offer affiliated sales or something. There was a big story about a standing desk company thst had to deal with that iirc
How did 'skilled' programmers recover when a daemon crashed in Sys5 init-based systems? The init script ends after startup so you are stuck with a third party monitoring service that will often clash with startup functions making controlling system state really hard. systemd was worth it for that feature alone.
Linux userspace was a bunch of crufty, unmaintained tools from xinetd to logind (literally had no maintainer until system came along) to update-rc.d that additionally were not taking advantage of a lot of new kernel features like cgroups. systemd has done a great job moving the base layer of linux userspace forward.
The old world of cobbling together bash, sed and shell metacharacters was always hacky, insecure and broken as shit and we are way better off now with systemd.
One would ask himself how the BSDs manage to do it (no systemd), Android (no systemd), ChromeOS (no systemd), Solaris/Illumos (no systemd) ...
Your arguments hold no merit whatsoever. The fact is that all the problems you describe have been solved, properly, multiple times _before_ systemd entered the picture. The reasons behind systemd mass adoption were political and Redhat exerted a lot of pressure at the time and in many ways, still do.
You could use the same argument to disparage any technological innovation. Computers? Our ancestors did just fine without them and so do many people across the world to this day. But more ridiculous than that is your listing of Solaris and Android as systems without systemd. Solaris uses SMF which was one of the inspirations for systemd. SMF is much closer in spirit to systemd than it is to sysvinit or rc. The particular merits of systemd or bash scripts aside, using SMF as an argument for the later is just ignorant. Furthermore, even though Android doesn't use systemd, software written for Android is written in such a way that it doesn't interact with the init system at all. The typical user/admin has no access to the init system. I have no specific knowledge of ChromeOS but I suspect it is much like Android in this regard. The only example that really works for you are the BSDs.
"Closer in spirit" does not mean anything tangible in the real world, you are merely playing with words.
Solaris SMF is vastly simpler than systemd and has a much narrower scope and focus. I don't recall mentioning bash scripts in the post you replied to, so you are simply being disingenuous by presenting a false dichotomy.
I find it really hard to believe that you were unable to understand what I meant.
The complexity of Sysvinit is orders of magnitude less than that of systemd.
This whole thread is a discussion of the relative complexity between sysvinit and systemd. Sysvinit uses shell scripts to implement much of the logic around starting and stopping services. Any discussion of sysvinit and systemd is going to involve bash. It's disingenuous to pretend otherwise.
I will copy my post again, here, to expose your strawman or unwillingness to stop deflecting:
"One would ask himself how the BSDs manage to do it (no systemd), Android (no systemd), ChromeOS (no systemd), Solaris/Illumos (no systemd) ...
Your arguments hold no merit whatsoever. The fact is that all the problems you describe have been solved, properly, multiple times _before_ systemd entered the picture. The reasons behind systemd mass adoption were political and Redhat exerted a lot of pressure at the time and in many ways, still do."
This is the post you replied to, with arguments that (still) hold no merit. Now you are trying to shift this into something else rather than stick to the points I made _in this thread_. You pick and choose a reply of mine _from a different thread_. Moreover, you write: "This whole thread is a discussion of the relative complexity between sysvinit and systemd". No it is not. As I wrote: "The fact is that all the problems you describe have been solved, properly, multiple times _before_ systemd entered the picture."
I would take you more seriously if you stopped presenting one logical fallacy after another.
daemontools, or respawn from inittab. There are a number of perfectly reasonable possibilities, of which these are just two.
But more generally, you didn't restart daemons if they crashed. Firstly, because they used to be written sufficiently well that they never crashed, because competent people wrote them. Secondly, because continually respawning and crashing does no one any good.
Firstly, because they used to be written sufficiently well that they never crashed, because competent people wrote them.
If your deployment strategy depends on never having to run substandard software then you've already lost. Also, it just isn't true that older software was necessarily more reliable. It's just that when you found yourself maintaining poorly written software you just dealt with it through whatever means you had available. I remember having to use an IBM HSM implementation on AIX, something you would expect to just work because it was IBM software written for their own system on their own hardware, but in practice the filesystem kept invisibly crashing resulting in apparently corrupt files and I'd have to restart it every few minutes.
The thing is, most Linux distributions ran services this way for well over two decades. The world did not end, and the number of problems we experienced in reality were negligible. If we wanted automatic service restart on failure, then there were facilities for doing so should we chose to avail ourselves of them.
If something is crashing and requires a restart, then doing it automatically is at best papering over a problem the admin should be investigating. It's a mitigation, rather than a solution, and might well cause more problems than it solves.
systemd isn't bringing anything particularly new or noteworthy to the table here.
The thing is, most Linux distributions ran services this way for well over two decades.
So? That doesn't mean it was the best way to do things. Humanity existed for thousands of years without vaccines and still managed but that doesn't mean that disease wasn't a thing. Misbehaving services have always been a thing and they've always been a problem. I know because I've dealt with them. If you feel that other methods for dealing with misbehaving services are better, fair enough, but don't appeal to a mythical golden age where everybody wrote software without bugs.
I'm not in any way appealing to a "mythical golden age". I'm simply pointing out that the whole Linux world ran this way for over two decades without this being a critical problem, or even a problem of particular note.
Not only that, but automated service restarting was configurable if desired, albeit not the default. If you wanted it, it was doable with ease. This is not a new feature which systemd brought to the table, it was already available.
The sentence: Firstly, because they used to be written sufficiently well that they never crashed, because competent people wrote them. IS an appeal to a golden age. Because it's not true. People did write services that crashed and sysadmins had to work around them. I know this to be the case because I had to work with a particularly egregious example. Whether you think the older methods for managing them were better is one thing, but those problems existed and they caused lots of damage.
> How did 'skilled' programmers recover when a daemon crashed in Sys5 init-based systems?
Maybe the daemons didn't crash so often as now?
I never understood this new approach, which consists of writing a server process in a half assed way so that it crashes frequently, then solving that by putting a restarter service in front of it, done!
