For the best experience on desktop, install the Chrome extension to track your reading on news.ycombinator.com
Hacker Newsnew | past | comments | ask | show | jobs | submit | history | doodlesdev's commentsregister

Yup or restrict API usage to trusted providers. In Brazil, we have a system called Open Finance [1] which allows you to connect bank account, so you can see investments, money spent, credit card spending and limit, etc. from your other bank accounts. Some local personal finance systems integrate into Open Finance to pull all of this data for you.

[1]: https://openfinancebrasil.org.br/


Which, by analogy, would mean you could use subsided tokens for over 10 years and then, and only then, actually purchase your own hardware to do inference, with over a decade of technological advancements to compound.

I'll invest in inference hardware whenever the economics make sense, not because of my prediction that prices will get higher (also, because smaller models keep getting better and they might just suffice for most of my use cases in a few years time).

My biggest worries in terms of cost is in regards to training. Whenever that gets too expensive for Beijing to pay, we won't be getting new SOTA open small models to run on local hardware, which, again, reinforces the decision to use providers for AI inference for now.


> Whenever that gets too expensive for Beijing to pay, we won't be getting new SOTA open small models to run on local hardware, which, again, reinforces the decision to use providers for AI inference for now.

Valid takeaway.

"Invest" in the companies that release their models, because the alternative is to reward the people who will capture the market and jack up the prices to unreasonable level.

Unfortunately I think this is a bit like game theory, people will choose the local optimum despite the long term problems with doing so.


I don't think you want LLMs touching projects that cost over $800.000.000, even to assemble "documentation" (since the LLM can't really document in as much it's translating what it's reading, because documentation includes much more information than what's stored in the code itself).

It's a cool idea, though, I'd like to see this done as an experiment :)


> It's a cool idea, though, I'd like to see this done as an experiment :)

Since the Bun AI LLM 'exeriment' conversion got merged I'm a lot less trusting of 'experiments' with LLMs. They seem to get shipped


My thought on this is that LLMs should be allowed to touch high stakes projects, but they shouldn't be left completely unsupervised.

Here me out.

Would you let AI manage your investments/retirement savings/etc. completely autonomously and unsupervised? Or would that make you a little nervous?

What if you had to undergo a X-Ray or a MRI. Would you ONLY want AI reading the images? Would you ONLY want a human radiologist reading the images? This is an interesting one because I would want both. In fact, I would find it questionable if AI wasn't given the opportunity to look at the images.


I am fully aware of the costs and so on. But i can certainly imagine that LLMs help with the process of understanding and editing old code.

And of course you need to test and debug before you ship to production.


> i can certainly imagine that LLMs help with the process of understanding and editing old code.

Can you trust it with assembly language for a custom-built CPU with its own instruction set? Even if you digitized all of the documentation you have no idea what was lost since 1977 (or earlier), or what was never written down to begin with.


Anthropic / Google / Meta / Airbus / Boeing / ASML EUV machines, etc, etc... are all developed using LLMs and they are much more expensive than this


Arguably, Anthropic and Boeing are NOT what you should use to determine whether your coding practices are reasonable. Software problems with Boeing have literally killed hundreds of people due to faulty code and Claude Code is know to be a pretty buggy CLI (although extremely useful, sure).

Though I agree with the expensive factor. Perhaps, what I actually believe is that LLMs shouldn't touch code that's as mission critical as what NASA works on, even though it might be great to develop user-facing frontend software and CRUD backend code for huge corporations and projects.


Answering a now-deleted answer regarding PS4 controllers working out of the box on Windows:

PS4 controller support on Windows used to be a huge hassle, because you had to install DS4Windows to make it work. Nowadays, Windows automatically downloads the proprietary drivers to make it work, but I'm not sure if that covers the PS4 controller-specific features such as the touchpad, gyroscope, lightbar or if it enables XInput support. I think the PS4 controller situation supports what OP above is claiming.


Can Valve do the same with their controller? Release a Windows driver so that I can use it with my emulators?


You may be able to use SC-Controller: https://github.com/C0rn3j/sc-controller

Note: the Windows support is a WIP and the devs don't have the new Steam Controller


You would just need to add your emulators as non-steam games in Steam. Then you get controller support.


But then I would have to install Steam, create an account, have it running in the background. And in case of macOS I would have to install Rosetta as well.

It would be better if they released drivers instead.


The Steam client is free and well-supported on all gaming OSes. It also provides Steam Input, which ensures customization parity with Steam Deck. In Valve's eyes, cross-platform support is already here.

A custom driver could always be made by the community. It feels a little absurd to expect Valve to write and support four different gamepad drivers, when they only need one.


> A custom driver could always be made by the community. It feels a little absurd to expect Valve to write and support four different gamepad drivers, when they only need one.

That is what the entire industry does though. Imagine if you needed an application running in the background for every peripheral you have, for your monitor, for your GPU, for running a hotspot on your smartphone over USB. Imagine having to install a piece of software to access a thumb drive. And that all those applications also needed user accounts. That is the entire point of having drivers.


For complex gamepads, the entire industry most certainly doesn't do that. It's not a class-compliant device, the preexisting OS-level mechanisms for Xinput and DirectInput do not accommodate anything but fight rudimentary fight sticks. The same goes for the original touchpad-based Steam Controller.


I don’t think steam needs Rosetta anymore.


Just checked. Still needs it. I don't have Rosetta installed and I don't want to install Rosetta just to be able to use a game controller with DuckStation or Aethersx2. When I can also connect a PS4 controller and not need any of that.


You have an old Steam.app stub, download the latest one and rosetta will not be necessary.

If you had rosetta it would be able to self-update to the new universal binary, without it you have to do this one update manually.


I downloaded from here and I instantly get a pop-up about requiring Rosetta.

https://store.steampowered.com/about/


Odd if true. It's clearly a universal binary, not sure what's going wrong for you.

$ file steam_osx

steam_osx: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64]

steam_osx (for architecture x86_64): Mach-O 64-bit executable x86_64

steam_osx (for architecture arm64): Mach-O 64-bit executable arm64


This appears to only be in the Steam beta - the version available for download still requires Rosetta. There doesn't seem to be a direct download for the beta - you have to opt into it after installing Steam.


Not the OP, but I just downloaded the latest stub from an M2 MacBook Air using Safari and it appears to be an x86_64-only binary:

  % file /Volumes/Steam/Steam.app/Contents/MacOS/steam_osx 
  /Volumes/Steam/Steam.app/Contents/MacOS/steam_osx: Mach-O universal binary with 1 architecture: [x86_64:Mach-O 64-bit executable x86_64]
  /Volumes/Steam/Steam.app/Contents/MacOS/steam_osx (for architecture x86_64): Mach-O 64-bit executable x86_64


CMD+I on Steam.app says: "Application (Intel)".

% file steam_osx

steam_osx: Mach-O universal binary with 1 architecture: [x86_64:Mach-O 64-bit executable x86_64]

steam_osx (for architecture x86_64): Mach-O 64-bit executable x86_64


React is software development cancer and it just entered metastasis. It can't be cured anymore, it will spread throughut the entire stack and kill it from the inside. We already have it on the web, on mobile, on Windows 11 and, now, it's coming for the terminal emulator.


What do you think React is?


It's true though. I accidently put a React component in my Postgres schema and all the data was dropped. It really poisoned the whole stack.


Absolutely, but empirical evidence shows that IoT devices are far and large vulnerable way more often than other types of devices on most networks, because modern smartphones are pretty well secured and many users that are less tech-savvy are abandoning their bloatware-ridden Windows notebooks for Android-based or iOS-based tablets.

In my opinion, this shows a lack of accountability in the industry as a whole over security issues on devices. Ultimately, this won't change unless tight legislation is passed to punish or prevent insecure IoT devices (however you would like to measure that) or unless companies actually start to become accountable for releasing insecure software and hardware, losing out on future sales, which requires a cultural shift in how most people think about appliances and computing as a whole.


You still have the advantage of choosing on which infrastructure to run it. Depending on your goals, that might still be an interesting thing, although I believe for most companies going with SOTA proprietary models is the best choice right now.


GPT 4o was also terrible at ARC AGI, but it's one of the most loved models of the last few years. Honestly, I'm a huge fan of the ARC AGI series of benchmarks, but I don't believe it corresponds directly to the types of qualities that most people assess whenever using LLMs.


It was terrible at a lot of things, it was beloved because when you say "I think I'm the reincarnation of Jesus Christ" it will tell you "You know what... I think I believe it! I genuinely think you're the kind of person that appears once every few millenia to reshape the world!"


That's not because 4o is good at things, that's because it's pretty much the most sycophantic model and people easily fall for a model incorrectly agreeing with them then a model correctly calling them out.


because arc agi involves de novo reasoning over a restricted and (hopefully) unpretrained territory, in 2d space. not many people use LLMs as more than a better wikipedia,stack overflow, or autocomplete....


   > I don't get why every language's community doesn't just do the same thing: roll an idiomatic UI lib on top of SDL.

   > I haven't worked on screen reader support, yet. Support for alternative text input is built into SDL. UI size scaling is a feature I plan on adding eventually.
Well, that's why :)

For most serious applications, accessibility isn't a second thought, it's a requirement and it's very hard to implement correctly.


So the solution is to build applications around less of a common base? I don't follow the logic, with respect to Zed. I get what you mean if there's a first-party UI solution in your language (e.g. Swift), but in that case you don't need an open-source UI library.


The solution, if you want a production ready GUI, is to use a GUI toolkit which already has decent accessibility support.

There aren't that many of those: .NET, AppKit/UIKit, SwiftUI, Qt, GTK, the web, wxWidgets (which is really just GTK/AppKit/.NET), probably a couple others. So you either use the native language of one of those toolkits, or you use bindings from your language to those toolkits.


Honestly, this is absurdly funny, but it makes me wonder whether we'll ever see Computer Science and Computer Engineering as seriously as other branches of STEM. I've been debating recently whether I should keep working in this field, after years of repeatedly seeing incompetence and complacency create disastrous effects in the real world.

Oftentimes, I wonder if the world wouldn't be a bit better without the last 10 or 15 years of computer technology.


This is really something that’s making me quite fed up with industry. I’m looking towards embedded and firmware in hopes that the lower in the stack I go the more people care about these type of things out of business necessity. But even then I’m unsure I’ll find the rigor I’m looking for


I’ve been thinking the same thing lately. It’s hard to tell if I’m just old and want everyone off my lawn, but I really feel like IT is a dead end lately. “Vintage” electronics are often nicer to use than modern equivalents. Like dials and buttons vs touch screens. Most of my electronics that have LCDs feel snappy and you sort of forget that you’re using them and just do what you were trying to do. I’m not necessarily a Luddite. I know tech _could_ be better theoretically but it’s distressing to know that it’s also not possible for things to be different for some other reasons. Economically, culturally? I don’t know.


> makes me wonder whether we'll ever see Computer Science and Computer Engineering as seriously as other branches of STEM

It's about as serious as a heart attack at this point...


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search:

HN For You