axman6

I wasn’t expecting to personally know two of the authors, but having Accelerate included makes sense.

After reading through the relevant threads, I'm completely on the side of the LLVM CoC committee, this user is just wasting their time. Asking for minimal steps to reproduce an issue is the bare minimum for report issues on open source projects, it is not the job of the developers to show that there is an issue, particularly when some of them attempt to do that, and are also unable to do so. The AI content in the LLVM and Mesa threads was actively misleading, confidently stating absolute nonsense, not even close to anything that was true, but still 100% confident. It's misinformation, bordering on disinformation.

It actually reminds me of the the [OSS Sabotage book](https://www.cia.gov/static/5c875f3ec660e092cf893f60b4a288df/...)'s section on General Interference with Organizations and Production (page 28):

    (11) General Interference with Organizations and Production
        (a) Organizations and Conferences 
            (1) Insist on doing everything through “channels.” Never permit 
                short-cuts to be taken in order to expedite decisions.
            (2) Make “speeches.” Talk as frequently as possible and at great 
                length. Illustrate your “points” by long anecdotes and accounts 
                of personal experiences. Never hesitate to make a few appropriate 
                “patriotic” comments.
            (3) When possible, refer all matters to committees, for “further 
                study and consideration.” Attempt to make the committees as 
                large as possible—never less than five.
            (4) Bring up irrelevant issues as frequently as possible.
            (5) Haggle over precise wordings of communications, minutes, resolutions.
            (6) Refer back to matters decided upon at the last meeting and attempt 
                to re-open the question of the advisability of that decision.
            (7) Advocate “caution.” Be “reasonable” and urge your fellow-conferees
                to be “reasonable” and avoid haste which might result in 
                embarrassments or difficulties later on.
            (8) Be worried about the propriety of any decision—raise the 
                question of whether such action as is contemplated lies within 
                the jurisdiction of the group or whether it might conflict with 
                the policy of some higher echelon.

Do your job

"I'm a volunteer, my job is to choose where I volunteer my time, and I won't be volunteering it for free for this".

The Mesa project example(https://gitlab.freedesktop.org/mesa/mesa/-/issues/13022) is even more deranged - I came to this story from someone on Mastodon recommending people proactively ban this person from their project. I'm not personally in favour of doing that, but this is the closest I've been to thinking that's a reasonable thing to do to prevent actively wasting time on nonsense busywork.

This would have me astroturfing it out the window after seeing this nonsense.

The output in their Mesa project bug report is outright misinformation, it sounds completely plausible but is absolute nonsense. This is the true danger of AI, it is so convincingly confident that people forget to question it, or in this case, don't even have the tools to begin questioning it. It's actively unhelpful at best.

Thats absolutely not what they asked for, no one was able to reproduce the issue, so they asked for clearer instructions on how to reproduce the issue and were met with hostility. It's not the job of OSS developers to debug someone else's scripts just to then start debugging the actual issue. This is the absolute bare minimum of any bug report, if you think there's a bug but no one else can observe it, in the first instance you have to assume it's something to do with their setup, until shown otherwise. The addition of not just wrong, but completely misleading AI summaries just makes the job of an OSS dev harder, they now have to start debugging the bug report itself to try to figure out whats parts are even facts at all (hint, most of the AI generated content was completely wrong, but sounded plausible).

Personally, the developers of both the LLVM and Mesa projects were far kinder and patient than I would have been, most OSS developers aren't just not paid to work on these projects, but are usually paid to work on other things. Taking up their time with this nonsense is very insulting to them, and the attitude that they owe the author anything at all is, as stated in the LLVM ticket, exactly what pushes many developers out of OSS development.

Notably, Apple joined the seL4 foundation, as they use it in several of their products: https://sel4.systems/Foundation/Membership/ (Not sure if they've stated publicly which, but it's been pretty well known for a while now).

Oops, yes indeed! Was working from memory and should’ve checked.

The video side of things is super interesting - 4k60 ProRes is an absolutely insane amount of data (something like 12GB/s IIRC?), and the addition of ACES really makes it usable for professional work where a larger mirrorless from Sony/Panasonic/Nikon/Canon wouldn't be practical.

I also found it very interesting that their pics of this feature were with Davinci Resolve on the screen and not Final cut Pro - I guess when it comes to colour, there's no better tool.

This isn't really new for Apple, they've been doing as much AI stuff on device as possible, there isn't really any change with the A16 as far as I'm aware, just more bigger.

Siri is nowhere near Apple quality standards as it is. had a fun experience with Siri the other day where I ended up sending someone the message "I'm just leaving now what the fuck are you doing", because it heard me, and showed absolutely no acknowledgement. Not the sort of message I ever want to send to an ex, but here we are.

The only thing worse than Apple fanboys is anti-Apple fanboys projecting.

No one is going to claim this. The fact the Pro gets 10Gbit USB 3 _is_ interesting (particularly for anyone using the phone for video), but certainly not revolutionary or genius.

They used to sell the case, and each airpod separately (with the total for all three being the same as a new pair), but it looks like they stopped? It was very useful when I ran over my airpods case with my LandCruiser, and it got a bit wonky (but was amazingly still fully functional).

That sounds highly unlikely, the one that came with my MBP supports everything up to Thunderbolt. But USB is ridiculously complicated, and sometimes better cables fail on shitty devices; I've seen it a few times with camera equipment where I really needed the cable that came with it because higher specced ones just didn't work.

Paul, are you actually for real right now? Did you really just say "We deleted all your data, and its your fault. We did whisper into the wind three times, you should have heard it. No, there is no chance of recovery"?

You might have literally deleted people's whole businesses, companies, who employ real people, who have families, now need to figure out how to continue. Not least of which, your own. If the company survives until Christmas I will be shocked; no one can trust your company ever again - your core business is storing other people's data, and you deleted it, for many, completely without warning.

I guess people still use Mongo even after finding it doesn't achieve any property of the CAP theorem, maybe some people will keep using a database provider with a track record of intentionally deleting their paying customers' data.

There just aren't enough adjectives for astonishment to adequately describe this situation.

I hope you offer Jay Clifford some support, he's clearly been put in the awful situation of having to explain the decisions of others and deliver the awful news. If I were him, I would be in need of serious mental health support, this is an absolutely awful thing to have responsibility for without any ability to rectify.

Last time I checked, Sydney is not in the EU.

What future customers? After seeing this astoundingly terrible behaviour for a company with "DB" in their main product's name, I can't imagine anyone ever making the decision to trust InfluxData again. I know I certainly won't, nor will any company I work for.

Am I going crazy, or has the obvious implementation of such a change been missed on people? If they were proposing taking a multi-threaded app and splitting it into a multi-process one, I would predict they would find a hell of a lot of unexpected or unknown implicit communication between threads, which would be a nightmare to untangle.

Going the other way, there is an extremely well understood interface between all the processes which run in isolation: shared memory. Nearly by definition this must be well coordinated between the processes.

So the first step in moving to a multi-threaded implementation would be to change nearly nothing about each process, and then just run each process in its own pthread, keeping all the shared memory ‘n all.

You would expect performance to be about the same, maybe a little better with the reduces TLB churn, but the architecture is basically unchanged. At that point, you can start to look at what are more appropriate communication/synchronisation mechanisms now you’re working in the same address space.

I just don’t understand why so many people seem to think this requires an enormous rewrite - having developed as a multi-process system means you’ve had to make so much of the problematic things explicit and control for them, and none of these threads would know anything at all about each other’s internals.

That's not really the point, no one is claiming this is supposed to be for general purpose workloads. If you know you need this sort of relatively small, super low latency cache, then this is a great solution, but those usecases are very niche - though so are most applications where an FPGA is the appropriate solution.

The article has everything to with an FPGA accelerated NIC connected service though. Did you perhaps misunderstand what's going on? Because your comments make it sound like you've missed the point.

I think you could definitely get into a loop where you have two values chasing each other around, offset by some number of cycles, where all their positions are full, and they keep evicting each other when they get to the array where they hash to the same index. It's certainly not an idea situation but you can limit the likelihood of it happening by keeping the load factor in check, and probabilistically all these chains should eventually terminate.

Put simply: No. The native code generator for aarch64 is relatively new, and is bound to have bugs in it that haven't been caught, as others have mentioned, because no one thought to test for this specific thing. There's already a patch for this bug, and a new regression test to catch it. These things happen in all compilers, and all software, relatively often.

I don't understand how a bug in GHC has blown up more than any bug in any recent GCC or clang - probably because the bug reporter decided that hyperbole was going to be their tool of choice instead of behaving like an adult.

I have to disagree with vm this, Haskell is by far the most powerful imperative language I’ve used, because it allows me to abstract what I mean by imperative programming.

I don’t have time to go into details but nearly every statement you’ve made here is in my opinion wrong, other than the difficulty in debugging (and there are very good reasons why this is difficult).

I’ e never found it hard to write fast Haskell, because I put in the effort to learn how to do it. People forget they also put in the time to learn how to write fast C++, and Java; it’s a very large portion of any software engineering curriculum, it’s literally what algorithms is all about. People find writing fast Haskell hard not because it is fundamentally hard, but because they were never taught how.

due to the lack of native accommodations to bind into fast code, or even into GPUs.

I have no idea what you mean by this, GHC provides a very good FFI, and there are libraries for binding to Rust, R, Objective-C and others. We also have Accelerate for data processing on GPUs, which includes runtime compilation of native code for both GPUs and CPUs.

On the contrary, when you can move your complexity into the type system, the. You have just taught your compiler how to check that you are using things correctly, and that is insanely useful in large scale software.

it’s not terribly useful

Well, it’s been paying my wages for the past eight years, so it’s incredibly useful to me. Are we services “very specific projects”? Are data processing systems? Are geospatial data munging? Are financial systems? Those all sound like mundane, every day projects, and they’re exactly what I’ve been working on.

And when it comes to “actual work”, that’s where Haskell truly shines - being able to fearless refactor code and iterate until the compiler is happy again is my favourite feature of Haskell. It’s not the “neat type system”, it’s the ability to not have to keep the entire project in my head at absolutely all times because I might forget to make a stupid change the compiler should have caught for me. The productivity is massive, once you’ve invested the time, but it does take time and it is an investment.

This argument is literally “the documentation for this domain I don’t understand is bad because I refuse to learn the domain”.

I use the lens library all the time and those docs make perfect sense, particularly if you apply just the teensiest bit of logic and thing “Could a setter, perhaps, set something?”. It’s a DSL, and you don’t understand the domain - I’m sure you’d have a great time explaining this function from LLVM without referring to any other part of the documentation to give it context https://llvm.org/doxygen/group__LLVMCCoreValueInstructionGet.... What’s a GEP? Under the rules you’re applying to the lens documentation, I’m not allowed to look that up, because it should be immediately obvious.

I couldn’t agree with this opinion less - lens is incredibly elegant, and very consistent. It is a DSL, and you need to spend some time learning the domain, but once you do you’ll find it hard to live without it. If that’s the way you use the library then you haven’t spent any time to learn how to use it.

I’m sorry, but this is an astoundingly ridiculous point of view. Those type variables CAN’T be named anything better because they could be absolutely anything at all, that’s the point of generic types.

You are complaining that a single function within a library doesn’t describe the whole abstraction the library is built on? Should every single function, operator and type include the whole fucking lens tutorial so you don’t have to go and find it?

I suppose every web library should include an explanation of IP, TCP, UDP, HTTPS, url encoding, compression and anything else that is needed, on every single function too? Christ, I cannot believe how incredibly dumb your take here is. Libraries in every single language provide some kind of preamble in their documentation which covers what abstraction that library provides, and Haskell is no different; the particular library you have chosen to misunderstand is INCREDIBLY general, the documentation is actually amazingly precise, if you have taken the time to learn what an optic is.

I genuinely think you should be ashamed of this opinion, because it shows that you’re both willingly ignorant, and proud to state that fact publicly.

Stick any structure in DynamoDB and you’ve already halved your nesting depth due to its encoding a superset off JSON in JSON. Then start encoding more complex structures like the ones the others have mentioned and these limitations start to bite pretty quickly.

As a side note, the Haskell implementation also supports numbers of arbitrary size, again limited by memory, for both parsing and encoding.