Odd. I installed a new Thunderbird on a Windows 10 install just a couple months ago, and it picked up the self-signed cert on my mail server just fine. Unless by "recent builds" you mean something newer than October.

"Make sure a white male won" You appear to be spewing back whatever blog you last read that claimed the Puppies were racist and sexist.

Right there in the Wired article is a woman who was on the Sad Puppies recommended list. She excused herself when the politics showed up.

That Correia and Togerson are racists is also laughable. If you believe it, show some evidence.

The Sad Puppies opposition worked hard to push the narrative that Puppies are racist and sexist.

Their racist/sexist accusation comes down to "If Puppies are not FOR promoting Hugos for authors because of non-white race and non-male gender, then Puppies must be racist/sexist." Now there is a fallacious argument. The old "if you're not for us you're against us" nonsense.

Go executables are static by design. It is pretty great to be able to copy it into place and it just works. Add a couple other build options to remove the ability to bind to external C code and include a Go DNS resolver, and the binary can be put into a completely empty container. Now that's great. It's the difference between 8 MB and 300 MB containers.

The arguments about fixing bugs in shared libraries do apply, but that's a problem with containers too, so you need a policy for rebuilding containers with bugs as well as Go binaries with bugs.

It should not, indeed it must not matter that Firefox loads data from a dodgy website. It has to be safe to read it, render it and run the Javascript.

Because if it isn't then the browser is doomed to be cracked and exploited anyway. Attackers can break into "safe" websites and put their scripts there. Or buy advertisements to their malware.

So all the worry over loading links from untrusted sites is foolish because you cannot trust ANY site on the Internet. Not really.

There's a better argument to be made over the privacy implications.

Oh sure, why not backport DX12 to XP.

It would only involve porting all of the internal kernel changes, driver support, DLLs, etc.

So then what, you'd have Windows 10 with a XP shell on top. Yay.

It would be almost exactly like porting DRI3 from Fedora 22 back to RHEL 5. You merely need to recompile kernel, glibc, Xorg, glib, gtk, gnome and KDE.

Get right on that.

Compressed log files? Binary files, unrecoverable if they experience data corruption.

XML like tags? Structured data tagging. Also markers for resync in case of data corruption.

In fact, not very different from the systemd journal.

What big new feature or driver do you want to see added to Linux next?

I'm sure Linus has systemd opinions but I doubt he can answer "Why" because he didn't write it. Linux the kernel doesn't care what you run as init. It can run /bin/sh as init (sort of).

And what if they did have a serious underground baby sitting ring? I could see one teenager acting as a coordinator, taking a 10% referral cut from each deal. One such teenager, acting as the manager for all of his or her friends, handling schedules and such, could exceed the levels easily.

And if you don't think teenagers can handle business and money like that then you haven't heard about high school drug dealers.

But my point about babysitters was that they are an example of the cash economy. Other work often paid in cash is lawn care, snow removal, food trucks, computer repair, auto maintenance, handy-man work of all kinds.

A lot of time those jobs are done off the books and the cash is used for entertainment spending, like beer.

Any rules or restrictions on a Basic Income plan are a bad idea because checking and enforcing those rules needs a big bureaucracy with investigators and enforcers. I can see an immediate cheat already of just working off the books for cash, thus being "unemployed." More than a third of the US economy is already untaxed cash transactions. (Seriously, who pays teen babysitters in anything but cash? And do you think that they track it and pay taxes on it?) No need to make it more.

Just pay everyone the exact same amount and save all the money you'd otherwise spend on making rules.

I agree. Linux has stayed focused on code. Code that works. The questions are always about what problem does it solve, what does it do better, is it faster, is it backward compatible...

Let me guess...

You buy the cheapest panels available and drive them from a VGA port.

Oh yes. I am so sure that your test plans include such unlikely things as your customers deciding to run your app on a Pentium III with no SSE support. That's when you discover that the compiler settings are defaulted for SSE support. Or you discover that a shared memory file is being used by an old software version and a new software version at the same time, resulting in disagreements about exactly what should be locked when. Or maybe you find out that if a customer opens more than 1024 file descriptors your app starts to get silent memory corruption and eventually crashes. (POSIX, select(), FD_SET with fds higher than FD_SETSIZE). Did you check every single POSIX resource limit before using the system libraries? Did you do it correctly?

You can have 100% test coverage and still fail in the real world because of issues with the hardware, libraries and operating system.

You surely must realize that the real world contains so many possible ways to break software that you can't possibly test them all. At some point you just have to go for it.

The kernel parts have always been free under GPL2.

The part of this that is worth money is creating patches to apply with this system. Patches that won't crash the machine or corrupt data.

Or that's how I think the headlines should read.