nicoburns
nicoburns on Hacker News
Testing touchscreen experiences for other devices is the main thing I can imagine actually using this for.
> As an occasional "pinch to zoom that thing centered on my fingers, and adjust it to show what I want to someone 10 feet away" tool: it's fantastic. I could learn the key combo, but "use two fingers" is dramatically easier to remember and control.
Perhaps, but on a Mac you can already do this via the touch pad.
Definitely appreciated. The increased weight is the one downside of my M1 laptop over my earlier 2015 Macbook.
Good news: batteries on are a similar exponential curve. Just a decade or so behind.
Yep, and if it's anything like previous transformative technologies: the internet, and 100 years earlier the railways, a lot of people are going to lose a lot of money overbuilding the wrong things along the way.
I'm pretty sure electricity demand in the UK has been declining in absolute terms, not just per capita.
> I'm highly skeptical that a battery + inverter (w/o solar), using time-of-use for payback would ever make pure financial sense.
Ever? Batteries are 10x cheaper today than they were ~a decade ago. If that trend continues for even a little longer, they'll be absolute no-brainer like solar is today within the next 5 years.
2026 seems to be roughly the break-even point. And whether it's worth it depends on where you live (greatly affects the cost of both installing a system, and buying energy from the grid).
> I don't know how you guys in Europe managed to gaslight yourselves into justifying regression of social and technological development
Many of us believe that the alternative is a serious risk of severe climate change that would be much more disruptive. Not being able to use your washing machine at night is going to seem like the smallest of minor inconveniences if crops start failing and we don't have food, or cites end up underwater triggering mass migration into neighbouring areas and that leads to large scale societal conflict.
Of course, if you don't believe that those things will happen then caring about climate change seems irrational. But belief in (anthropogenic) climate change is the mainstream view on all sides of the political spectrum in most of Europe.
This was needed. A lot of large businesses ban Firefox because they don't have these kind of controls. I can't test Firefox on my work computer because company policy prevents it being installed. And that kind of thing really hurts Firefox.
There are `rsx` macros in Rust that work with a regular `cargo build` and retain IDE support.
Four-hour grid-scale batteries wouldn't have helped the Texas winter crisis much. But something like a 10 or 20kwh home battery would have helped a lot (it wouldn't sustain normal energy usage for that long, but the individual home owner could choose to ration the available power for critical functions).
You think the Oil and Gas industry is cleaner?
Recylable is important because it means we don't have to mine as much.
The cost of batteries has gone down somewhere between 60-80% over the previous 10 years (and my understanding is that trend is expected to continue due to a combination of new technologies (e.g. Sodium Ion) and increased scale). So that one seems totally reasonable. A little conservative if anything.
I can't comment on the cost of Gas Turbines.
Yes, but it's the only option if you want to retain a maintainable code base. And you can always slow down. You'll probably still be a bit faster than you were before.
Reasonable, although I've taken a different approach. Either closing such PRs, or treating them as very detailed issues and having my own LLM build the actual fix.
My repos probably don't see as much traffic as SQLAlchemy though.
Were you reviewing the changes? I've seen lots of projects with this problem. But if AI PRs have to pass the same review bar as any other PR then it shouldn't be an issue in theory (if you can actually maintain the discipline).
> You also know nothing about how I use electricity in my home
I don't
> Where I live isn't relevant,
But where you live does matter. Average monthly household energy usage in the EU is 200-400 kWh. In the US it's more like 800-900kWh. So what you consider "normal energy usage" may vary considerably by where you live.
At 200-400kWh total usage, 30kwh starts to look a lot more significant. So you should at least consider the possibility that it's not that energy usage from AI is insignificant, but that your existing energy usage is wasteful.
> here are talks of John Ternus potentially selling Apple Silicon for server and AI use.
At the very least they ought to consider doing a macOS-based server chip. Given how many providers are racking Mac Minis these days. It's mostly for CI testing for code deployed to Apple platforms, so it very much supports their business.
I've tried most of them. Certainly all the Open AI and Anthropic models. Fable is still the best I've tried. But it still struggles with architectural issues.
> Linking is super slow even in debug
Linking is normally slower in debug btw (because of the debug info)
Something like a 4k RGBA texture being 30mb and you need at least 2 for a swapchain. Of course you might not be rendering at 4k, but those are just output buffers before you even start counting application memory.
Good idea - thanks.
FWIW:
- Binary sizes start around 8mb if you're using GPU rendering (you can go smaller with CPU rendering, but you probably want the GPU). Our full browser app which pulls in things like sqlite, http cache libraries, etc is 20mb. Those usually compress to about half for distribution (.dmg, .appimage, etc).
- Base memory usage is something like 100mb (mostly from the graphics stack). I'm hoping to be able to bring that down a bit, but I think you can't realistically get much lower than 60mb with modern graphics. And to be perfectly honest we currently have an issue for RAM where it will often jump to more like 300-400mb after a little use. And I haven't fully gotten to the bottom of that yet.
That does happen, but these days they tend to add that kind of thing to the spec (and the test suite). There was a minor drama several years when WHATWG (representing browser vendors) effectively took over the spec process from the W3C because they were fed up with the W3C taking an idealistic viewpoint, and speccing things that they couldn't actually implement.
I have a working (and not vibe coded) implementation of a "browser engine for apps":
https://github.com/DioxusLabs/blitzSo far it's only HTML/CSS (and we have our Rust-based framework to write the apps in). But it has been designed for fast incremental rendering, so it could be extended with JavaScript support quite easily.
As someone who has spent the last 3 years implementing a browser engine from scratch full time (that currently passes ~half the 200k "css" tests that test style/layout/rendering), I find that (without a lot of close hand holding) the AIs are very far from being able to do this. They'll give you something that passes the tests, but it will do it a ridiculous way be far too slow to be useful (and is wrong architecturally such that it's not going to converge on a better solution).
Basically everyone I know who doesn't have a tech job is struggling for money / feels like the world is unaffordable for them atm. Those without jobs are struggling to get them. And those with jobs are scared to change even if they don't like them.
And from what I read in the media, a lot of the economic indicators are backing this up: discretionary spending is down, private debt levels are rising, etc. All signs that the slack in the system is disappearing.
> LLMs require orders of magnitude more memory than we could have ever used before
That's true. But will anyone have any money to pay for the LLMs? The AI market is currently being heavily subsidised by, ultimately, everyone else. But the economy in general is looking extremely dire at the moment, and that seems unlikely to last.
From what I'd read, SHA256 in git is showing every sign of being another IPv6. In particular:
- It's implemented in a non-backwards-compatible way
- The benefits over the older model are a bit nebulous
- There's a large amount of tooling that needs to catch up, and little sign that there is movement there
(I did a quick test, and I'm seeing between 15-20% for
https://github.com/servo/stylo which is a macro-heavy crate. I guess it only matter for crates you're actually editing though, macro will already be cached as part of "entire crate is unchanged")
> Another thing that can easily improve performance is changing the global allocator, but I've seen teams that measured 10% perf improvements in their own metrics decide against going with anything other than the "default".
Yeah, although I think there's more of a trade-off there. Alternative allocators can add significant amounts of compile time. Whereas, modulo maturity, I think a faster linker is more of a pure win. I would imagine we will make wild the default linker at some point if development continues on the trajectory it seems to be on.