ATsch

This was supposed to be a joke but it's actually how people here talk about racism.

Every single one of them. But if we are to make a ranking, I think spreading climate denial to protect your oil empire does do a lot make you uniquely loathe worthy.

Good thing events can only ever be blamed on one single individuals actions.

I/We are using the latest 7.3.0 with Prometheus, however most of the issues are more general. I think they'd be hard to prioritize as they are so minor (outside of perhaps a "minor bugs only" sprint or similar, as some projects do). But they do add up very quickly.

To illustrate, here's some of the paper cuts that instantly come to mind: mod-s not working in panel editor, gradient fill incompatible with series overrides, various missing tooltips, missing query error reporting and syntax highlighting in variable editor, variable editor needing many clicks for most common actions, hidden variables can only be changed by repeatedly opening and closing the settings, some dashboard settings pages being easy to accidentally close without saving, g+[key] keyboard shortcuts randomly not working, random scroll jumps with multiple queries in a panel, switching between cursor modes with mod+o is super slow, Prometheus autocomplete not working when editing existing queries, clicking the dashboard name filters by folder while clicking the folder name shows all dashboards, adhoc filters silently don't work, etc.

The "not responding" one specifically happens a lot while editing queries. It'll randomly decide to evaluate the query while I'm typing, get thousands of results and lock up.

I disagree with the idea that they can't work on both, but I have to agree that this is my #1 wish for Grafana. The frontend is filled with an incredible amount of ux papercuts, performance issues and silent breakage that make me resent having to edit dashboards at all. It's a perpetual state of being scared my next click will trigger "a script is not responding" or randomly break something I won't know how to fix.

It feels like Grafana Labs is stepping into the same "if it doesn't help sales tick checkboxes it's not getting development time" trap so many B2B companies hit as they grow and it's a shame. I wish there was something else I could switch to.

While it's true that originally X was network transparent, this hasn't truly been the case for a long time now. All modern applications (including the ones you've listed) render the whole window locally for performance reasons. This does not work over the network. Instead, xorg will transmit a picture of the window, giving you an in many ways worse version of VNC. The only difference is the level of integration with other programs like SSH.

This makes no sense. The community of people working on Xorg aren't gone, they're just working on wayland now. Wayland was designed by long time Xorg maintainers. This "hostile takeover" narrative is complete FUD.

This has been working by default in all compositors for a while now, it is not a new feature or project.

There's been a recent trend to increasingly move more compute capabilities into NICs. This has been going on for a while, but has gained a new dimension with cloud providers. For example, with their "Nitro" system, AWS can more or less run their Hypervisor entirely on the NIC and completely offload the network and storage virtualization from their servers. This development is likely to continue. FPGAs are going to play a significant part in that because they allow the customers to reconfigure this hardware according to their needs.

Likely just simple glue logic. Things like converting one protocol into another, doing some multiplexing or some simple pre-processing or filtering on some sensor data. They're incredibly tiny (2x2mm) and use little power, so they pop up in designs pretty regularly.

It is very likely that the packets of this comment traveled through several FPGAs to get from your computer to my screen. Yes, they are definitely more niche than CPUs. But niche products have really high margins and people willing to pay for them.

FPGAs are already incredibly popular. They're just mostly in things you are unlikely to personally own or know about. You're going to find at minimum one, but probably more FPGAs in things like big routers and other telecom equipment, e.g. cell towers, firewalls, load balancers, enterprise wifi controllers, video conferencing hardware, test equipment like oscilloscopes, sensor buoys, scientific instruments, MRI machines, LIDARs, high end radio equipment, or even just glue logic tying together other components, like in the iphone.

Unrealiability can often be a feature to police, as it is with field test kits and drug dogs. The false positive rate makes them a good tool to provide plausible cover for further police action. By simply running enough unreliable tests or letting the dog sniff long enough, it is practically guaranteed that they can find at least one reason to justify their action.

Same thing with other junk science like bite mark forensics. If you need someone convicted, show it to 10 "experts" and one of them will say they match beyond reasonable doubt.

Ah, that's interesting, I assume this is the link:

https://dropbox.tech/infrastructure/lossless-compression-wit...

Shows a significant improvement in compression code and some examples of checks that can't be elided. I guess this makes sense because it's pretty much the worst case scenario for bounds check impact.

I can still personally say that every time I've blamed rust's bounds checks, I was wrong.

EDIT: neither the unsafe flag nor the macro appear to be present in https://github.com/dropbox/rust-brotli/ anymore today, removed some time in 2017. So it seems they found some other way to deal with it?

I think rust has indirectly shown that the performance impact of bounds checking mostly neglegible in practice. Even in very high performance code, I've never seen anyone turn them off for performance. This makes a lot of sense considering that on modern CPUs everything except cache misses is basically free, so a single unlikely branch compare usually just does not matter.

The only exception I can think of is accessing lots of indexes in a loop, where getting good performance requires rust programmers to insert awkward asserts or casts to fixed length arrays to get the checks to optimize out[1]. But afaik that's mostly because the bound checks impede other loop optimisations like vectorization, not because the checks are slow themselves.

[1] (e.g. when you access indexes 1 to n randomly, assert n < length before)

Ah, that's good, despite being six years late. However, I do not think there is any good reason for code written like this to exist in the first place. Bounds checking is easy and fast (even if less so in C) and things you consider "trusted" can become untrusted easily and quickly turn otherwise minor bugs like file type confusion into critical vulnerabilities.

I remember fuzzing stb_truetype and it finding hundreds of trivial segfaults instantly. Perhaps they fixed some but I can't advise using these with any untrusted data, it's obvious security is usually not a priority.

> And X.Org's driver architecture could be replaced completely (in fact, it could be made to run on the same stack as Wayland)

Many distros do this already. Both for graphics drivers (xf86-video-modesetting) and input drivers (xorg-input-libinput)

It's not that developers don't need these CPUs, it's just that there's a lot more gamers than developers, and most of them will buy laptops or be provided workstations with Ryzen PRO or Threadripper processors.

No, this is exactly the common coding mistake removeprefix/suffix is here to adress. The strip() family removes all characters in the string you pass, so it removes not just "prefix" but also "efix", "prefixix" and "effxpixpefiii".

It is overly broad, but not because of this. AFAIK there is precedent for arguing cryptographic keys and even code implementing drm algorithms are such a "device". This is extra great because as soon as you slap any encryption or algorithm that could feasibly be called "drm" into your code, it becomes illegal to reverse engineer. This is being used by lots of companies, but most memorably for me by John Deere to make repairing their tractors a jailable offense.

I think it will take more time to say that for certain. Warp is an exception, but most of the recent improvements to Firefox were initially prototyped and developed in the experimental Servo engine which was to my knowledge intended to eventually replace all of gecko. Most of the team for that has been let go.

I think the thing to be worried about is: what will happen when they run out of stuff that's already in the pipeline? Will they be able to execute the sweeping changes they'll need to do to stay within reach of blink long term? Or will they have to concede like opera and edge did.

For context, when Alyssa Rosenzweig initially started this reverse engineering effort, she published releases via TOR out of fear of retribution from ARM. This was in response to the mysterious firing of the main person driving earlier reverse engineering efforts with clear hints at pressure from ARM. All allegedly of course, please don't sue me.

All of this hackery with hundreds of registers just to continue to make a massively parallel computer look like an 80s processor is what something like Itanium would have prevented. Modern processors ended up becoming basically VLIW anyway, Itanium just refused to lie to you.

If they do it that directly, sure. But on a large enough (time)scale, incentives are the only thing that matters. And they'll certainly think hard about putting their fancy new research that would help a competitor into their openly licensed chips from now on.

Both the US and USSR knew about neural networks for decades before fast massively parallel hardware made them feasible long after the end of the USSR, so I'm not sure that's a useful comparison. The development of the internet was driven by the state out of national security concerns, not market forces and was not widely used during the USSRs life, so I'm not sure that one is helpful to illustrate the OPs point either.

Could you give any examples

Especially interesting with all of the talk about the unique levels of innovation that capitalism brings that supposedly justify all of the other stuff.

The concern is more that nvidias culture has historically been being overall hostile to parterships. Which works great for what Nvidia is doing right now, but is probably bad for a company that depends heavily on partnerships.

This is already legally required by GDPR but I guess it's good for apple to check for it.

They're not going to be sitting in the board room panicking about the at most few ten thousand sales to DIY enthusiasts they're losing. Especially not with shipments declining by ten or so million per year.