idop

The problem isn't that the website is not HTML-only, but rather that it is JavaScript-only (practically-speaking). If you're using NoScript, or otherwise have JavaScript disabled, you get an empty page with nothing but an error message.

> Tesla is the largest EV manufacturing the world.

It isn't. See BYD Auto.

They did use the full title. Yours is a subtitle, look again.

So apparently this OceanGate company is a VC-funded startup or some such founded "to make underwater exploration cheaper and accessible to private citizens" (Wikipedia quote). Tells me everything I need to know about how this all came to be.

This doesn't tell us whether new submersibles were ever built.

That was one thing. I think the biggest thing was that in Reddit you got to chose the type of content you wanted to see. You more or less curated your own feed. The moment Reddit started shoving "You might like this" into the website, I knew it was soon to be over. Reddit no longer wants you to choose what to see, it wants to decide for you, like all other social media websites. And the reasoning is unassailable, all those other websites have made their owners obscenely rich, so why not /u/spez too?

You may be right, but keep in mind that the comparison with Apollo isn't a fair one. There are many third party Reddit clients. Red Reader (which I use), Reddit Is Fun, Stealth, Infinity, Dawn, and many more. You'd have to combine all of those. You may still not reach Reddit's official app's numbers, but it is probably not a negligible percentage of Reddit's userbase.

1. As mentioned, this article is about Full Self Driving Beta Pro Black Edition, but it's important to note that it is commonly confused with Autopilot, and vice versa. Even the most die-hard Tesla fans routinely confuse the two (example: you saw "Self-Driving System" and somehow that registered as "Autopilot").

2. It's only click garnering nonsense if you don't bother reading the article.

3. I respect your thoughts and experiences with Autopilot, but your experience will never invalidate other people's experiences, nor cold hard data.

4. If bad drivers will always be bad drivers given any tool (which I'm inclined to agree), doesn't that invalidate Elon's claim that FSD will actually allow you to be an absent driver, one that doesn't look out the windows, plays games and drinks alcohol?

It's not paranoid, it's simple observation. Anything that can be abused by someone, will be abused by someone. The question is whether the benefits overshadow the potential for abuse. In this case, they don't.

The solution being (supposedly) easy doesn't discount the severity of the issue. Owners must be informed and aware.

Yes, and good that they do.

While this may be a valid sentiment, it doesn't change the fact that you're reading bullshit. Many of the articles created by the aforementioned system are of a medical nature, for example, and the information it spits out is often patently false.

The thing is AI generated content, much like illiterate college kids masquerading as journalists, are a symptom of a media that is fueled only by money and corporate interests.

I know someone who has an SEO business, and AI-generated is pretty much all he's doing. He has hundreds of websites with nothing but AI-generated content and all the SEO shit and they're all top of the pop at Google.

Ever since I know him I believe more and more that many websites I find are AI, because they all look exactly the same and have the same formatting for their content: articles are short enough to be read in a few minutes but not short; articles are split into 4 or 5 subheaded sections; at least one of the subheadings begins with "which", "how" or "why": last section is often a conclusion or summary; text reads like an idiot wrote it; text absolutely doesn't give you the information you were looking for.

OpenAI, DALL-E, Stable Diffusion and all the others are already being exploited to "improve" these websites. The pictures, the videos, the text, it's all fake.

Cool, thanks!

I was waiting for this, but it doesn't mention which version of Perl 5 this is.

Alright, that's enough internet for today, good night everybody.

So she knew she was going to prison, and decided to bring kids in to the world to grow up without a mother? That's even worse.

Edit: typo

Yes. And you should negotiate at the dealership too.

> I own a Tesla and have had no problems with customer service.

Good for you, really. That doesn't invalidate the countless horror stories that prop up on those forums multiple times a day.

If there's anything Tesla seems to have proven, it's that dealerships are actually good (or at least better) for the customer. Tesla customers are a captive audience wholly dependent on a startup with no customer service. Non-Tesla customers have virtually infinite options, and someone to actually take care of them. I suggest you read even the most die-hard Tesla fansites and see just how bad Tesla's anti-dealership strategy is for the customer.

Was Martin Shkreli's and Jordan Belfort's prison terms significant?

In any case, when you ruin people's lives, any prison term is insignificant.

He shouldn't bother. Soon he'll be offered a book deal, a movie deal and an exclusive interview deal that will net him enough money to live comfortably for at least a few decades. Not to mention that after his not-so-significant prison term he'll become a motivational speaker at 50 grand a pop.

If you ask me: a low-level SCM framework.

Thanks for pointing out my errors, I now see where I was wrong.

> That's not the alternative, who develops like that?

As an independent contractor working with many different companies, unfortunately, virtually everybody.

To be clear, what I'm advocating for is that feature branches get rebased regularly by the developer until PR-time and a clean merge into the mainline. I usually recommend squashing to one commit but do not insist.

I can definitely see how those intermediate commits can provide more information, but there's a tradeoff. More often than not, they do not provide me much value, and instead give me bloat, so I prefer to keep things simple.

Telling developers not to do something is like telling a kid not to push that red button. The average developer chooses what's easiest _right now_ and thinks it's someone else's job to fix the mess at PR time. And they're afraid, because that one time five years ago they ran a rebase without knowing what it does, and lost some code without knowing it's actually right there in the reflog, and since then they are deathly afraid of Git. I know how to use log and diff and all the others quite well, but most don't. So I'm trying to make things easier on everyone in the long term, not the short term.

That's fine of course. Personally, I prefer to make things as easy as possible to understand at that unspecified but probable future date when a customer opens a SEV1 and I have to consult with the log, among other things. Make it idiot proof later, when time is _really_ of the essence, rather than now, when you're being artificially pressured to deliver that story for the sprint review in two hours.

At the end of the day everything depends on the organization. In a hectic startup where requirements change on an hourly basis and releases are made several times a day, I would absolutely insist on keeping the log linear and as clear as possible. Tags are important, of course, but they're not that useful for analyzing a repository.

When I say "the evolution of the product" I really mean "the "evolution of the code". When a small feature branch with 5 commits - four of which say "wip" and the last one says "added color support" - gets merged as is, and all relevant information is held hostage by whatever Git platform the company is using this week and not inside the repository itself, the log is not useful to me regardless of any strategy.

But in a different setting I would not necessarily insist in the same way.

Oh definitely, a clear and enforced strategy and conventions are more important than anything.

Also, keep on mind that Git is the engine with which Continuous Integration is made. CI is developers integrating with the work of one another on a regular basis. If the product changed since you started working on your new brach, then your branch is stale and you need to integrate with the recent changes. Why wait until you're done to find out that your branch can't be merged anymore and you have to make a ton of changes when you can keep on top of things at regular intervals and make the final merge as easy as possible, not just for you, but for the code reviewers, the QA guys, the DevOps guys, everyone.