gbrown_

Both Intel's oneAPI and AMDs ROCm/HIP stacks success are obviously tied to (and part of) the success of each companies future products. And today I'd bet AMD will come off better. They have multiple contracts for HPC systems with their future GPU products as well as an existing presence in consumer gaming products.

Intel's effort seem to be banking on the Aroura system at ANL. Beyond that I don't know who's lining up to by Xe GPUs? Though I guess oneAPI will fit into whatever they do further down the line.

> Seems like yet another CUDA alternative.

How many real alternatives are there though aside from OpenCL? Not to mention if you're interested in targeting something that isn't an Nvidia GPU.

This has been posted a few times before, some of the more active previous discussions.

4 months ago: https://news.ycombinator.com/item?id=24849452

~3 years ago: https://news.ycombinator.com/item?id=16862925

For anyone interested in the topic I highly recommend checking out Dr. Michael P. Frank's work. This video is good one to start with https://www.youtube.com/watch?v=IQZ_bQbxSXk

I'll repeat my comment [1] about the resolvd addition. It's premature to be "reporting" this as the design intent is not something that's been publicly shared as of yet. Unsurprisingly this is just making users ask "What about dhclient(8)?".

[1] https://news.ycombinator.com/item?id=26279566

Yes they have their own but at least for ssh on macOS it is built against LibreSSL.

    ~: sw_vers
    ProductName: macOS
    ProductVersion: 11.2.1
    BuildVersion: 20D74

    ~: ssh -V
    OpenSSH_8.1p1, LibreSSL 2.7.3

The presenter also has a blog post about this topic [1] for which there was a prior discussion on HN [2].

[1] https://ollef.github.io/blog/posts/query-based-compilers.htm...

[2] https://news.ycombinator.com/item?id=23644391

Previous discussion https://news.ycombinator.com/item?id=25556286

I like undeadly and OpenBSD in general but this "reporting" feels a little premature as dhcpleased(8) has just shown up too. It seems these daemons are being introduced as part of a larger co-ordinated design change. I imagine clarification about the motivation behind these changes will appear in the near future (before the 6.9 release).

[1] https://marc.info/?l=openbsd-cvs&m=161435621007396&w=2

Title truncated to fit within HN character limits.

Yup in particular Brian Behlendorf from Lawrence Livermore National Laboratory has been a major contributor to ZoL/OpenZFS.

It's going to be so good to finally have an open source option for large storage building blocks. It's of particular interest to those of us in HPC as if you are building a large parallel file system and you don't want re-build times to suck your options are basically one of the following.

- IBM's GPFS

- Panasas' PanFS

- Xyratex's -> Seagate's -> Cray's -> HPE's GridRAID in Clusterstor/Sonexion prodcuts

Though ZFS and dRAID will likely show up in that last one in the future.

Have you perhaps mixed up my comment with this one https://news.ycombinator.com/item?id=26152783?

I was just asking about your thoughts of how outside of trading jitter is seldom considered. I appreciate it's off-topic from the actual HN post but I was curious given your experience in trading.

I'm aware, I was talking about jitter in general.

Oh I wasn't meaning specifically in the context of NTP, just generally.

> dedicating a core for your NTP

Heh as soon as I read this I thought "algo trader?". If you don't mind me asking outside of trading how often do you see systems seriously manage jitter (specifically I'm thinking about interrupt management). I'm in HPC and whilst some such management is present it seems seldom thought about.

Just to add, pledge can be called repeatedly throughout the program to reduce the behaviors that are permitted unlike seccomp.

Another interesting point is ROP gadgets, which OpenBSD tries to reduce by preferring to avoid EBX/RBX registers [1]. This and more on the subject can be found in this paper [2].

[1] https://marc.info/?l=openbsd-tech&m=150869222214001&w=2

[2] https://www.openbsd.org/papers/asiabsdcon2019-rop-paper.pdf

Saw this paper via Reyk Flöter's tweet [1] noting work done in OpenNTPD around constraints [2].

[1] https://twitter.com/reykfloeter/status/1357311912623689729

[2] https://marc.info/?l=openbsd-tech&m=142356166731390

Yup, my only major gripe is with Spotify matching the volume from my desktop (application level) to my phone (system level) and vice versa. I've seen lots of reports of this "feature" being more of a bug and reporters being told to go through hoops. So many I've not bothered pursuing it myself as I'm sure it's hopeless.

Perhaps you wish to have both your collaborative and your presentational works on the same (in this case near de facto) hosting provider.

I'm on the fence about this, I don't think Bram or other Vim devs are malicious towards Neovim. But the repeated implementation of equivalent features with incompatible APIs (terminals, async, and now faster scripting) doesn't look good.

See the "PHASING OUT INTERFACES" section of the link in my comment for Vim's reasoning of moving away from this. Personally I broadly agree with it as I've seen many people struggle setting up plugins that depend on other things like python.

That said the approach Neovim took of shipping Lua built-in addresses the same portability/ease/reliability of use. In retrospect I think this is a better course of action.

I'm really not a fan of the decision to overhaul Vim script. It seems this is driven from a desire for Vim script to be faster [1]. I've not needed Vim script to be "faster" but I don't use very complex plugins. That said a lot of Vim script is written in sub-optimally. Using a more functional approach is faster (though still not "fast"), e.g.

    $ cat loop.vim
    let sum = 0
    for i in range(1, 2999999)
      let sum += i
    endfor
    quit
    
    $ cat fold.vim
    call eval(join(range(1, 2999999), '+'))
    quit
    
    $ time vim -u NONE -S loop.vim
    vim -u NONE -S loop.vim  7.08s user 0.09s system 99% cpu 7.198 total
    
    $ time vim -u NONE -S fold.vim
    vim -u NONE -S fold.vim  2.03s user 0.13s system 99% cpu 2.166 total

I think its cryptic reputation comes form the use of normal mode commands and regex within scripts. There certainly are warts, like the user's 'ignorecase' setting permeating to many places in the runtime. Which I'd love to see fixed and whilst may also represent a breaking change for some scripts would be far more easily adoptable.

[1] https://github.com/brammool/vim9/blob/master/README.md

Previous discussion from a couple of weeks ago.

https://news.ycombinator.com/item?id=25742547

The post doesn't specify requirements or application level targets for performance. They show a couple of good latency improvements but don't describe the business or technical impact. The closest we get is this.

> If this database isn’t performing well enough, it can cause API errors and timeouts for our subscribers.

What are the SLO's? How was this being met (or not) before vs after the hardware upgrade? There's a lot of additional context that could have been added in this post. It's not a bad post but instead it simply reduces down to this new hardware is faster than our old hardware.

This is a very high level overview and ideally I would have liked to have seen more application level profiling, e.g. where time is being spent (be it on CPU or IO) within the DB rather than high level system stats. For example the following.

> CPU usage (from /proc/stat) averaged over 90%

Leaves me wondering exactly which metric from /proc/stat they are refering to. I mean it's presumably its user time, but I just dislike attempts to distill systems performance into a few graph comparisons. In reality the realized performance of a system is often better described given a narrative describing what bottlenecks the system.

Yes! Sadly a lot of people skip over this despite vimtutor pointing to it at the end. Copy/paste below as the text doesn't need paraphrasing, but also because a lot of comments here seem to be advocating vimtutor as something more than the "brief overview" it is.

    This concludes the Vim Tutor.  It was intended to give a brief overview of
    the Vim editor, just enough to allow you to use the editor fairly easily.
    It is far from complete as Vim has many many more commands.  Read the user
    manual next: ":help user-manual".

Not to be snarky but OpenBSD's random system has always seemed very elegant to me and seems like such a system could avoid this failure mode in systemd, video[1], slides[2].

That said it's good that the faulty RDRAND was discovered. As pointed out this isn't the first time processors (AMD particular) have had such issues. Do we need to just be skeptical of this and run RDRAND tests every time a new processor comes out? Or perhaps even each microcode update?

[1] https://www.youtube.com/watch?v=aWmLWx8ut20

[2] https://www.openbsd.org/papers/hackfest2014-arc4random/index...

I don't mean to say you have to be tech savvy to use Signal but it's mostly tech savvy people that want to use it.