Link to Original Source
Link to Original Source
Link to Original Source
Not at all. His message is, if you think it's real, then start doing science! He doubts it's real because the people who claim it is refuse to even try actual science -- you know, that thing where you document experiments and publish with sufficient levels of detail that allow the results to be independently verified.
Even if you think it's real, you have to admit that what they're doing is not science. Or at least, you have to admit that if you're honest and know what "science" is. It might be invention, but it absolutely isn't science.
A hydrogen bomb yields more energy than was put it, by a large margin.
Sort of, but most of it's waste energy. Show me a process where the amount of power you receive back into the power-grid from setting off an H-bomb is greater than the energy you used constructing it...
A patent will just be violated, and completely ignored. Keeping it secret is the way to go, similar to Heinlein's Shipstones. Place a tamper-resistant box at the client's location, set a meter to charge by the watt-hour, and be done with it. Someone tries breaking into the box, it completely obliterates anything inside showing how it works, or just does a big kaboom, Outer Limits, "Final Exam" style.
Ah, yes. One of Heinlein's most unrealistic, least believable premises ever, and that's saying a lot.
Meanwhile, in the real world, your invention will be reverse-engineered in a matter of months if not sooner.
What if I want a straight text log file that requires no other tools?
Then you write your systemd log in text format. If you can't figure out how to do that, you're not qualified to be reading the log file output.
Why would anyone even have a binary log on a *nix system?
It takes less space, especially if you're archiving them for long periods, causes less I/O in general and less disk fragmentation over time as you compress and delete them every day/week. Note that indeed, you do the same on most classic BSD or SysV init systems by compressing the old logs, requiring you to use a tool to dump them to text if you want to read them later... but that's not as efficient.
If you want binary log files that require tools to dump them to text, use Windows.
Do you turn off the compression of logs on your boxes, or do you admit that having to use a tool to read them isn't so big a deal when you aren't grasping at straws to justify why you hate a particular piece of software?
Python is my go-to language for quick code sketches, framework ideas, etc. That's the power of dynamically typed languages, it's very easy to throw code together to test ideas, and is what I value in "scripting" languages.
As much as I like Python, even with it's quirks like len() is a function on a sequence not a member, the one thing I despise is the whitespace-describes-structure. I have lots hours due to an auto-format of code run amok. Suddenly, all the code following an if-statement is now the body of that statement. It just doesn't make sense to not have block delimeters. With every other meaningful language under the sun using curly braces, why couldn't Python? I like the *idea* of clean code like Python code, and I enjoy reading Python code, but I prefer to have explicit block syntax.
As an aside about spelling mistakes, I agree, and Python doesn't help you there (unless you are reading a misspelled class field). One trick I use to fortify larger Python programs is to define slots on each class to explicitly define the members. If your code accesses a mistyped member name, that name will not be in the __slots__ list and the python runtime will raise an exception. Not only do __slots__ protect you from name typos, they are faster than regular fields for some reason. I've shared this tip with other pythonistas, and nobody else has heard of doing this; I can't believe others aren't doing this, too.
If the company running the auction misrepresented the car's condition, he can certainly take it up with them or their lawyers. But he has no reason to blame Tesla for his situation, at all. According to the article, they're not trying to force him into any service contract, or pay a huge fee (they even said they would waive the inspection fee). But they have got to be able to cover themselves if he does something like electrocutes himself or hits someone if a repair they weren't responsible for is insufficient.
There's no dark side of the moon. It's all dark, really...
Well, there is a darker side. It's just not always the same side.
First of all, I'm of the mindset that it's probably best to not list every issue fixed, and especially not list every bug reported publicly. Many bugs reports are bogus, and it's certainly possible for a large number of "reported issues" to detract from the true quality of the current version. For a new product I would never make this information public. But that's neither here nor there since in the OP's situation, they are public. So, let's go with that.
What I would do is based on a Freakonomics episode where a company (furniture company, or appliance company, whatever it doesn't matter) inadvertantly stopped advertising in some of their major-market newspapers. While it was an intern's mistake that this happened, what they found was that there was no impact (i.e. no reduction) of sales in those markets. So while a logical person would say, "Let's scrap advertising in those markets forever and keep the cash," the people in charge instead said "but we *have* to advertise." Preserving expectations/status-quo won out over rational thinking, and the difference was millions of dollars.
I would put a challenge to the marketing and sales departments. If they think public disclosure is hindering sales, let them prove it. Pull the publicly-visible bug tracking for a period of time and if the marketing and sales people are right, sales will go up compared to similar periods in previous years. If, however, customers are unhappy with the "secrecy", take that into account as a ding against the approach. But I'd be firm -- if you pull the bug info, the sales better increase.
Of course, before you issue a heavy-handed challenge to M&S, maybe just ask your existing customers about it. "We are considering pulling our publicly-visible bug tracking/reporting but have no plans to change our update cycle, just the reporting. How does this impact your business, and how does it impact your decision to use Product X?" Use that as a basis to continue current practice, or start the M&S challenge.
I also acknowledge I am anothing but a keyboard jockey in this horse race.
Although they plan to have translators to move old code forward, do you really trust automated translators enough to run them on huge chunks of production code?
Yes, certainly. It's called running the automated translator and NOT blindly checking in the generated code. There's no concern here.
Not sure if I follow the real name policy argument. Personally, I understand that people want privacy and there was a huge outcry when Blizzard also required real names as part of their RealID row out. But at the same time I think the issue that both Blizzard and Google wanted to address was cyber-bullying by hiding behind the anonymity of the internet.
You can tell people at a company are speaking from a place of privilege when they assert that using real names will reduce bullying/make people safer/etc. For many of us, using real names pretty much guarantees bullying and danger, and quite possibly even threatens our lives. From Blizzard, it really takes the cake. Like I'm going to put my life in jeopardy for the sake of a video game. And even if the threats aren't serious, many people would just rather avoid the hate and abuse to begin with, even if it's "only" verbal/emotional abuse. Some people use anonymity as a weapon, but most of us use it as a shield. Congrats for those lucky enough to not need it, but understand we're not all so lucky. Removing it just further marginalizes those who aren't privileged enough to be safe without it.