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.

If the name were an arbitrary word which didn't attempt to define itself, would that be any better? I don't see why the name must mean anything specific, nor why you should expect the name to explain what the project is. That's what the documentation or other descriptive text is for. That the name gives some understanding at first glance is a bonus.

PnR is "place and route", and is a very common acronym in the ASIC/FPGA/VLSI space. It seems fair to expect those who'd use this specialized variant of Yosys to also be familiar with PnR. For reference, here's [1] Yosys's PnR tool, which expands the acronym in its README title.

Realistically, if you're using Yosys tools, you're going to need to have some familiarity with the underlying flows anyway; in my experience they're very powerful but also pretty DIY. That's not great, but it's the reality. That's just the nature of the space right now, given the alternative is a ~$1M single user license.

[1] https://github.com/YosysHQ/nextpnr

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.

I had a few Windows Phones too. The thing I loved was the lack of hamburger menu: UX standards put controls at the _bottom_ of the screen, or on a pane accessible via swipe. It was all within thumb range. You never had to awkwardly reach to the other end of the display or use your other hand.

Other posts on the HN front page right now says largely the opposite of this headline [1][2]. She has appealed, but will be sent to prison nonetheless in the meantime.

This article title is editorialized and/or incorrect as far as I can tell.

[1]: https://www.theguardian.com/technology/2023/may/17/court-rul...

[2]: https://www.wsj.com/articles/theranos-founder-elizabeth-holm...

This isn't the point of the article.

The article is commenting on CPU design: area efficiency, power efficiency, design cost, etc. They're proposing that the reason x86 CPUs have historically beat ARM CPUs in performance, and the reason ARM CPUs have historically beat x86 CPUs in power efficiency, has nothing to do with the design of the ISA itself. You could build an ARM CPU to beat an x86 CPU in high performance computing, or vice versa. They're saying that the format of the instructions and the particular way the operations are structured isn't the driving factor. Instead, it's just a historical arteract of how the ISAs were used.

In other words, yes, there are plenty of ecosystem reasons that these two (and potentially, more) families of chips are better for some things vs. others, but if the two companies swapped their ISAs 30 years ago we might see exactly the same ecosystem just with different instruction formats.

Have you watched the talk or only read the title? The "death" in the title does not mean what you suggest it does.

My reading of the statement (and understanding of other reporting on this subject) is that EXPO alone can trigger this issue. Calling EXPO overclocking feels somewhat disingenuous to me.

EXPO is akin to Intel's XMP. The RAM stick reports timings and other settings that it can handle and then the motherboard/user selects one to use. The profiles are needed because the official JEDEC standard for DDR doesn't provide a mechanism for running up to the frequencies that modern RAM uses; e.g. if you buy a DDR5 6000MHz kit, it'll only run at 4800MHz or thereabouts until you enable EXPO/XMP. RAM is really never expected to be run at the base frequency (without EXPO/XMP). If you buy a prebuilt, it'll have EXPO/XMP enabled, and if you build yourself you always should be enabling it. If you have a RAM kit that's somewhat recent and don't have it enabled, you've likely wasted money on the RAM.

Intel has attempted to claim that XMP was overclocking and violated their warranty but my understanding is that they quickly backed off.

Yep. AT&T home ISP and AT&T cellular.

I saw the same. I'm in San Jose, CA. I could access Reddit, DDG, Google, etc., but Discord, Twitter and DownDetector were inaccessible. Both cellular and hardwire ISP. Didn't seem to be DNS. I am wondering whether it was a regional infrastructure/peering issue.

No, GitHub posts their received DMCA notices publicly and links to them from the takedown page. So 2) is a reasonable expectation and it isn't present here, suggesting the post title is pure speculation.

In this article, I interpret "pretty" to mean "readable". There is a sample of the alternative in the post. Raw mode requires an explicit carriage return to accompany each line feed if you want the CR behavior, so if the default panic handler prints its normal string, each line is horizontally indented to the end of the previous line.

There is no ASCII art.

Yes, my understanding (as purely a bystander) is that even the most aggressive fires in the past have allowed time for a mayday. See for example UPS flight 6, with a huge uncontrolled lithium battery fire: https://en.m.wikipedia.org/wiki/UPS_Airlines_Flight_6

In general, onboard fires are one of the most dangerous scenarios in-flight, as I understand it. Crews are trained extensively for it.

I think this is, in part, what the analysis in the article concludes — even a fire would have to cause a very specific, never-before-seen combination of failures to lead to the outcomes observed from the outside.

In other words, they know that the "65 Watts" in their title is meaningless but included it anyway. Saying "88 Watts" would at least mean that the number referred to an amount of power. But even then, it's the actual draw as measured on the traces that really matters, rather than the marketing material.

Not making any judgements re: whether this chip or others are power-efficient, just making it clear that the power number in the title and body was chosen by a marketing team and has no other meaning.

Since it's in the title, note that the TDP on AMD cores (Intel and the rest too, but especially AMD) is misleading. They engineer the number to fit their marketing; there's no expectation that 65 watts of power is put into nor dissipated out of this chip.

It's probably reasonable as a relative comparison point to other recent AMD parts, but that's about it.

See e.g.: https://www.gamersnexus.net/guides/3525-amd-ryzen-tdp-explai...

In response to those complaints GitHub now requires you to accept the invitation before you're added. And it always sent an email notification and allowed you to leave voluntarily.

Additional context: https://en.wikipedia.org/wiki/D._B._Cooper

"github.com" when logged in returns a 500 for me, while repo/user pages and the logged out home page work fine. Seems it's specific to the home feed/trending repos/etc.