kaelinl

This messed with me too. At work our primary development environment is a farm of older CentOS machines. They all lost support with this vscode upgrade. It probably impacts hundreds of people. I had to send out instructions to downgrade and pin your vscode version while we look for a workaround.

I get that it isn't entirely within the vscode team's control (Electron chose to make the switch), but even then, it really interferes with a lot of people's daily development needs. These systems aren't particularly old or out of support.

People who must diagnose, modify, optimize, or establish procedures for operating the car think of it in the context of the system. Meanwhile, people who strictly want to move forward think of it as the accelerator.

Likewise for engineering tools. If you'd like to use a simple abstraction as your mental model, you'll be able to operate the tool in the basic sense without issue. But as engineers, when something goes wrong with our tools we often don't immediately bring it into a mechanic. We need our tools to do very specific things, and we must understand what they did each time we perform an operation. We establish workflows that build on top of the tools and depend on the tool matching our precise expectations of its behavior. In essence, we are the mechanic for our own car.

And of course, our needs are much more diverse than "make car go forward". So inevitably, we run into trouble more often. What user-facing function of a car is as precise, powerful or intricate as a textual merge or reconciling two diverged work histories? There are many ways those operations can be done, and questions the user must answer about their desired result.

In what way is Alaska a "budget carrier"?

Maintenance protocols are a mix of manufacturer recommendations and carrier/maintenance contractor SOPs, which are then approved by the manufacturer and FAA.

I haven't used it personally, but my understanding is that AMD/ROCm-accelerated backends for PyTorch overload the "cuda" device and module so that ROCm shows up as CUDA for feature testing. They want to make a transition seamless, and lots of existing code checks for CUDA, so they do what's necessary to make that existing code run.

The question is not how many prior messages there were in the conversation. That's irrelevant for context window purposes. The question is how many tokens there are between the prompt and the point where the reply breaks down.

How many tokens was that before it diverged from your original request? If it filled the context window, the original prompt would no longer be available to the model and it would start predicting just based on the repeated word. That certainly looks like what's happened here, although I haven't checked what model context size you used or how long the response is.

Yeah, my understanding is that it's pretty universally Perforce in game dev. For them it's the large file versioning. I work at an ASIC firm and we similarly use Perforce; to some extent for the large file versioning, and to some extent for other general scale benefits.

MLPerf does not test hardware. Companies submit results from their own hardware. This is what each company chose to submit.

Yeah, I think it's fine, and even very positive, to be sharing their view. However, I do agree with the sentiment that "hardware" used as a generalization is confusing. There are lots of different kinds of hardware and the article does not clarify it anywhere, although you can derive what they mean through the later descriptions. I had to re-read the intro once I had figured out what "hardware" meant.

Personally, I'm also a software engineer who ventured into hardware, and even am now professionally doing hardware design. I find that perspective worthwhile. But I am an ASIC engineer, which is a very different kind of hardware than PCB design or integrating ICs on a breadboard. The lessons and realities of each are different. So I would find it helpful if the post (and title) clarified what specific field was being discussed.

While I'm fully in agreement that Discord has fundamental problems, this article doesn't seem of sufficient quality for HN. It is "unfinished", and in practice that apparently means "makes claims and doesn't justify any of them". So while we can choose to agree or disagree about the claims, we don't know what the author meant. That the article is written in a flippant and dismissive tone doesn't help.

I agree that discord has objectionable philosophical foundations around centralization, data retention and privacy. Additionally, the rate at which they're crapping out annoying, intrusive anti-features is excruciating — think "sound board", "super reactions", "clips", etc. It's profoundly clear that Discord is grasping at straws trying to find any way to motivate people to pay for their fully functional free product, and the way they've decided to do it is to add ways to annoy other users and count on the "meme potential" to entice people to pay get access to them. Overall, Discord is a very effective text and voice chat app, but now requires a lot of accessibility settings and preference toggles to make it usable. It's very sad the direction Discord is heading, given how effective it was as a tool not long ago.

This, in turn, will spawn user scripts which work around the detection. Any client-side solution will be an arms race between Google and user script/adblock devs. The only real way to prevent it is to withhold the video stream from the CDN until the client has streamed the full ad and/or bake it into the video stream. My impression is that Twitch does this for its live streams (although not VODs).

Yeah, I had the same experience with the BeagleBone AI-64. Their documentation is extremely lacking. To make it worse, the whole point of the board is TI's ML inference accelerator, and TI's documentation and sample code for it are completely useless.

The Beagle hardware is great but it seems to me they just don't have the resources or focus to support the hardware they release.

(2017)

"In-editor chat" is mentioned as an example (the only example in the post, as far as I can tell) of a restricted API feature. Since the post insinuates that the restricted APIs are done out of malice/with anticompetitive intent, I think we'd need to see an example of the vscode devs being asked for access to this "in-editor chat" API and know how they reply. Is there an example of this?

Otherwise, it seems to me that assigning malice isn't justified. It's surely a fast-moving/evolving feature which was added recently, and stabilizing the API for general use means they have to support it in that form ad infinitum. Sure, it would be ideal if they committed to that from the beginning, but I can understand the schedule pressure and priorities.