Preferences

BigJono
Joined 2,422 karma

  1. There's a few comments speculating about fraud, but they're way off on the timeframe. I was approached about this project like 7-8 years ago. It's probably been in development the whole time.

    1k * 250 * 8 * a team size of 20 is about 40 mil in salary for engineering, could be low, add on their $12M testing, $4.1M just for the design (vintage Deloitte), some cloud cost blowouts and a bunch of dickhead managers and scrumlords, plus the putrid enterprise-grade 3rd party map/data system they've gone with, I bet that wasn't cheap. All up it's in the right ballpark for a typical well-intentioned trainwreck consulting project.

    Wouldn't be the first project to blow out because of a bunch of enterprise Typescript, Java and C# devs that can't deliver anything.

    Welcome to the Aussie tech industry.

  2. This is what I'm doing for my game, I didn't know it was actually a thing in some big titles too, that's reassuring. I landed on it because it was a huge code simplification compared to every other method of handling transparency, and it doesn't look completely shit in the era of high resolutions and frame rates.
  3. Yeah, there was an entire season about ending the war on drugs and how it was the only thing that actually worked lol.

    Also, they caught the drug kingpin at the end of the show by physically following his lieutenants to a warehouse full of drugs and arresting them all on the way out. The only thing the wiretaps were used for was to build a conspiracy charge against the leader, who had been standing outside for months/years doing face to face meetings with everyone that was arrested, clearly being the one in control of every conversation. If somehow that's not enough to charge someone with conspiracy then it seems removing a small amount of freedom to change that would be far preferable to reading everyone's messages and banning encryption.

    "The Wire proves the need for mass surveillance" is the dumbest take I've ever heard. It literally shows the complete opposite.

  4. I might be reading parts of it wrong, but I think that's a different sort of thing to the research in the article.

    Sugar is a very indirect cause of heart attacks, everyone knows that most heart attacks are a culmination of decades of diet and exercise habits. It's still worth researching everything to do with that, but it's pretty low value research because it's hard to draw any actionable conclusions from it other than "eat healthier and exercise", which is already well known.

    The research in the article is talking about a direct cause. Bacteria exists on arterial plaque, viral infection triggers bacteria to multiply, something about that process causes the plaque to detach and cause a heart attack. If that ends up being a rock solid cause and effect, even for a subset of heart attacks, that could lead to things like direct prevention (anti-virals before the heart attack happens) or changes in patient management (everyone with artery disease gets put far away from sick patients) that could directly and immediately save a lot of lives.

    The post you replied to was saying that the data from the study isn't as strong as the article and headline make it out to be, which is usually the case. For this one though I'm reading that less as "it's a nothingburger" and more as "it's a small interesting result that needs a lot of follow up".

  5. > In this process, deletion rather than expansion of the wording of the message is preferable, because if an ordinary message is paraphrased simply by expanding it along its original lines, an expert can easily reduce the paraphrased message to its lowest terms, and the resultant wording will be practically the original message.

    This bit has me perplexed. If you had a single message that you wanted to send multiple times in different forms, wouldn't compressing the message exponentially limit possible variation whereas expanding it would exponentially increase it? If you had to send the same message more than a couple of times I'd expect to see accidental duplicates pretty quickly if everyone had been instructed to reduce the message size.

    I guess the idea is that if the message has been reduced in two different ways then you have to have removed some information about the original, whereas that's not a guarantee with two different expansions. But what I don't understand is that even if you have a pair of messages, decrypt one, and manage to reconstruct the original message, isn't the other still encrypted expansion still different to the original message? How does that help you decrypt the second one if you don't know which parts of the encrypted message represent the differences?

  6. The thread before with someone flogging off their educational book they wrote "with Claude in an afternoon", as if anyone would benefit from investing days or weeks of learning effort into consuming something the author couldn't be fucked spending even a single day on, that one was well crafted satire, right?

    ...right?

  7. I wish. As far as I can tell the Venn diagram of people building piles of shit with NPM and people building piles of shit with LLMs seems pretty close to a circle.
  8. I can give a bit more context as someone that got on WebGL, then WebGPU, and is now picking up Vulkan for the first time.

    The problem is that GPU hardware is rapidly changing to enable easier development while still having low level control. With ReBAR for example you can just take a pointer into gigabytes of GPU memory and pump data into it as if it was plain old RAM with barely any performance loss. 100 lines of bullshit suddenly turn into a one line memcpy.

    Vulkan is changing to support all this stuff, but the Vulkan API was (a) designed when it didn't exist and is (b) fucking awful. I know that might be a hot take, and I'm still going to use it for serious projects because there's nothing better right now, but the same extensibility that makes it possible for Vulkan to just pivot huge parts of the API to support new stuff also makes it dogshit to use day to day, the code patterns are terrible and it feels like you're constantly compromising on readability at every turn because there is simply zero good options for how to format your code.

    WebGPU doesn't have those problems, I quite liked it as an API. But it's based on a snapshot of these other APIs right at the moment before all this work has been done to simplify graphics programming as a whole. And trying to bolt new stuff onto WebGPU in the same way Vulkan is doing is going to end up turning WebGPU into a bloated pile of crap right alongside it.

    If you're coming from WebGL, WebGPU is going to feel like an upgrade (or at least it did for me). But now that I've seen a taste of the future I'm pretty sure WebGPU is dead on arrival, it just had horrendous timing, took too long to develop, and now it's backed into a corner. And in the same vein, I don't think extending Vulkan is the way forward, it feels like a pretty big shift is happening right now and IMO that really should involve overhauls at the software/library level too. I don't have experience with DX12 or Metal but I wouldn't be surprised if all 3 go bye bye soon and get replaced with something new that is way simpler to develop with and reflects the current state of hardware and driver capabilities.

  9. C code is shorter than both assembly and Rust, it's not the same thing.
  10. > I became proficient in Rust in a week, and I picked up Svelte in a day. I’ve written a few shaders too! The code I’ve written is pristine. All those conversations about “should I learn X to be employed” are totally moot.

    fucking lmao

  11. People have 240hz monitors these days, you have a bit over 4ms to render a frame. If that 1ms can be eliminated or amortised over a few frames it's still a big deal, and that's assuming 1ms is the worst case scenario and not the best.
  12. Gee do you think maybe that's why all our software sucks balls these days?
  13. > That’s like saying the workers have all the leverage.

    ...they do? You can shuffle money all you want, if nobody can write the fucking code then you don't have software. I imagine it works much the same in any other field.

  14. No, what's toxic is building an environment like 99% of companies where juniors are told that everybody is the same and there's no point doing anything other than copy pasting whatever dogshit the "senior" next to them is typing into VSCode.
  15. You come off as incredibly arrogant too, you just don't realise it because you have the current mainstream opinion and the safety of a crowd.

    Do you know how fucking obnoxious it is when 200 people like you come into every thread to tell 10 C or Javascript developers that they can't be trusted with the languages and environments they've been using for decades? There are MILLIONS of successful projects across those two languages, far more than Rust or Typescript. Get a fucking grip.

  16. The comments are absolutely astroturfed to fuck as well, but you're right, there's at least some small signal in there, whereas average Google results have an amount indistinguishable from zero.
  17. They're the best of the bunch when it comes to PC parts, but think how far off they are in terms of usability compared to USB, or Ethernet, or HDMI, or Displayport, or those old VGA cables you had to screw in, or literally anything else. They only look good in comparison to the other power connectors.
  18. This shit is so fucking dumb. Sorry for the unhinged rant, but it's ridiculous how bad every single connector involved with building a PC is in 2025.

    I'm just a software guy, so maybe some hardware engineer can chime in (and I'd love to find out exactly what I'm missing and why it might be harder than it seems), but why on earth can everything not just be easily accessible and click nicely into place?

    I'm paying multiple hundred dollars for most of these parts, and multiple thousands for some now that GPUs just get more and more expensive by the year, and the connector quality just gets worse and worse. How much more per unit can proper connectors possibly cost?

    I still have to sit there stressing out because I have no idea if the PSU<->Mobo power connector is seated properly, I have no idea if the GPU 12VHPWR cable is seated properly, I'm tearing skin off my fingers trying to get the PSU side of the power cables in because they're all seated so closely together, have a microscopic amount of plastic to grip onto making it impossible to get any leverage, and need so much force to seat properly, again with no fucking click. I have no idea if any of the front panel pins are seated properly, I can't even reach half of them even in a full ATX case, fuck me if I want anything smaller, and no matter what order you assemble everything in, something is going to block off access to something else.

    I'm sure if you work in a PC shop and deal with this 15 times a day you'll have strategies for dealing with it all, but most of us build a PC once every 3 years if that. It feels like as an average user you have zero chance to build any intuition about how any of it works, and it's infuriating that the hardware engineers seem to put in fuck all effort to help their customers assemble their expensive parts without breaking them, or in this case, having them catch fire because something is off by a millimetre.

    This space feels ripe for a radical re-design.

  19. AWS KMS is great product branding. I've never seen another company so accurately capture how it feels to use their product with just the name before.

This user hasn’t submitted anything.