HN user

hunterloftis

1,459 karma
Posts26
Comments176
View on HN
blog.reve.com 1mo ago

The Layout Bet

hunterloftis
1pts1
news.ycombinator.com 3y ago

Ask HN: Did Bing miss their opportunity to compete with Google?

hunterloftis
3pts6
news.ycombinator.com 3y ago

Tell HN: The ThinkPad X1 Carbon is an excellent MacBook replacement

hunterloftis
135pts210
www.linkedin.com 5y ago

Getting into the Industry

hunterloftis
2pts0
news.ycombinator.com 5y ago

Show HN: Date Night Questions

hunterloftis
3pts3
datenightquestions.com 5y ago

Show HN: Date Night Questions – learn more about friends and loved ones

hunterloftis
5pts3
www.zdnet.com 5y ago

Fluree, the graph database with blockchain, goes open source

hunterloftis
23pts3
tableofsending.com 6y ago

Dungeons & Dragons, new friends, and an app to keep playing

hunterloftis
2pts0
priceonomics.com 6y ago

The Invention of the AeroPress (2014)

hunterloftis
147pts184
github.com 6y ago

A Go Roguelike

hunterloftis
1pts0
hunterloftis.github.io 9y ago

JS to Golang; Abundant concurrency in Go

hunterloftis
3pts0
hunterloftis.github.io 9y ago

Renamed Types in Go

hunterloftis
2pts0
hunterloftis.github.io 9y ago

Useful Constructors in Go

hunterloftis
3pts0
github.com 9y ago

Awaiting.js: fluent async workflows for modern JavaScript

hunterloftis
2pts0
hunterloftis.github.io 9y ago

Awaiting.js: the hero async/await deserves

hunterloftis
2pts0
www.youtube.com 9y ago

Promises are terrible; start using them (Nodevember)

hunterloftis
1pts0
dancerscode.com 11y ago

Why the Open Code of Conduct Isn't for Me

hunterloftis
42pts30
www.youtube.com 11y ago

Lessons JavaScript developers should learn from Game developers

hunterloftis
2pts0
devcenter.heroku.com 11y ago

Scalable Node.js session handling

hunterloftis
2pts0
devcenter.heroku.com 11y ago

Asynchronous Web-Worker Model Using RabbitMQ in Node

hunterloftis
2pts0
skookum.github.io 11y ago

Show HN: An old Verlet demo in JS + Canvas that I'd almost forgotten creating

hunterloftis
6pts1
greenlanguage.rustie.net 11y ago

Show HN: Album Release “8-bit” Raycaster in JavaScript

hunterloftis
22pts12
www.playfuljs.com 12y ago

A first-person engine in 265 lines of JS

hunterloftis
528pts97
medium.com 12y ago

Reinventing Code: software development as a creative process

hunterloftis
4pts0
www.playfuljs.com 12y ago

Realistic terrain in 130 lines of JavaScript

hunterloftis
339pts56
10k.aneventapart.com 15y ago

The future of web gaming could be canvas; I learned a lot from this project

hunterloftis
3pts0
The Layout Bet 2 months ago

Yesterday, we launched a generative image model that competes with the top of the field. I figured some HN folks might be interested in this deep dive from the research team.

Watching them figure out how to make the best use of our relatively-limited resources has demonstrated "necessity is the mother of invention" for me. Instead of just "pour more money on it," they came up with a different training strategy / hypothesis (the title's Layout Bet), and it's exciting to see that bet start paying off.

Also: free random house you didn't want, design, or ask for.

If you've held onto vacant property for years or decades, you may have a specific plan in mind for it (like retirement).

Reynolds was in for yet another unwelcome surprise: The developer sued her for being “unjustly enriched” by the construction of the home on her land.

The developers’ lawyer told SFGATE in March that Reynolds appeared to be taking advantage of the developer’s mistake. “Keaau Development Partnership is the only entity that has suffered hundreds of thousands of dollars’ worth of losses,” Peter Olson said. “She’s trying to exploit the situation to get money from my client and the other parties.”

I'm glad the judge laughed that one right out:

The court has dismissed that case.

“The clear motivation of KDP and PJC was to cut corners to reduce construction costs,” the ruling read. “... The encroachment on Lot 114 is so great that the Court finds it has caused the complete destruction of Ms. Reynolds' estate as it had been originally held and enjoyed.”

Bugs Apple loves 6 months ago

In the context of laptops, I would agree (MBP's hardware just outclasses everything else, even if I prefer Fedora over macOS).

However, for phones, this just doesn't shake out. The Pixel 10 Pro for instance, has:

* A battery that outlasts the iPhone 16 Pro by an hour

* A slightly better display (higher brightness for outdoor use, higher PPI, higher color accuracy, same refresh rate)

* A better camera for still photography, especially HDR and low-light (although admittedly worse for video)

Given the weird take on x86 being inherently "more powerful" and the copy-pasted error from the marketing site (32W vs 32WH) this "article" looks like gently massaged advertising copy:

Alternatively, HP’s EliteBoard will bring Windows and a more powerful x86 architecture to the keyboard-PC form factor. HP says the EliteBoard will support Windows 11 Pro for Business and an AMD Ryzen AI 300-series processor with an up to 50 TOPs NPU. The device will be sold with a 32 W internal battery and is part of Microsoft’s Copilot+ PC program.

My takeaway from the read wasn't that it was trying to convince anyone to take any particular action, and even emphasized that the mediocrity of AI output as more people use it will be a benefit to the smaller number of people doing their own thinking.

It'd be perfect it just had a switch to inherit everything the page already has.

It does! <https://lit.dev/docs/components/shadow-dom/>

By default, Lit renders into shadow DOM. This carries benefits like encapsulation (including the style encapsulation you mention). If you prefer global styles, you can render into light DOM instead with that one-line switch.

However, shadow DOM is required for slotting (composing) components, so typically what I'd recommend for theming is leveraging the array option of each component's styles:

    static styles = [themeStyles, componentStyles]
Then you define your shared styles in `themeStyles`, which is shared across all components you wish to have the same theme.

That sounds like possibly a configuration issue rather than strictly performance (although I agree the symptom is worse performance). For instance, specifically the value "~60fps" vs something as high as 400fps sounds like running with vsync enabled vs. with it disabled.

Hey, I worked on this & totally agree - I want my tools to be editors, not slot machines.

My focus has been on the beta "Edit" feature, tucked away into the top-right when you're looking at a single image. It lets you directly manipulate the image as both a spatial canvas and a semantic structure.

All good points.

I suspect preferences will hinge on peoples' budgets for personal responsibility. As my non-digital responsibilities have increased, I've found it nice to be able to delegate to "the cloud" - even at the loss of independence & control.

If there were a personally-owned "cloud" setup, I would prefer that. A box that plugs into my fiber connection and provides the equivalents of the cloud services I use, with data stored locally and backed up automatically to a secure server. A man can dream.

I fondly remember locally-executing software with local persistence by default.

To provide a counterpoint, though, during that time my entire family shared one desktop PC. Looking around me, right now: work macbook, personal linux laptop, smartphone, steam deck. I suspect that the workflows that were "fine" in 1995 would really wear on me today. Especially the ones that involve migrating documents from place-to-place for collaboration while trying to maintain a canonical master copy somehow.

Today, because of de-facto reliance on the cloud, "setting up" a new machine - regardless of its OS - takes me about 20 minutes. If my laptop fell off of my bike, that would suck, but I wouldn't irretrievably lose important data.

There are downsides to the current cloud-first paradigm too, of course. But I don't think it's _all_ downside.

Because I wanted hardware that's already been tested end-to-end with not only linux in general, but the distro & version I'm using (Fedora 36).

Using the same hardware that Lenovo ships with linux out-of-the-box, as well as the same hardware that Red Hat employees use, is worth more to me than a couple of extra performance cores. CPUs have been "fast enough" for my use cases for years.

I don't know if the fingerprint reader works - I don't like them, so haven't tried to set it up (it's integrated into the power button, which of course does work).

I haven't spent more than 8-10 hours off of a charger, so I don't know what the death point is for the battery. At least a full day working & streaming.

I use Fedora, not Ubuntu, so I can't speak to Ubuntu's hibernation. Power management works seamlessly on Fedora: connecting/disconnecting battery, opening/closing lid when connecting/not, timing out to sleep, awaking on keypress or lid open, etc etc. All the annoying combinations that, previously, I've had issues with on Linux devices.

Thanks for the trackpoint tip! I do want to try to acclimate to it because that sounds like a nice workflow. It's hard to break muscle memory, though.

I agree the M1 is great hardware.

However, the feeling of speed is made up of much more than just the hardware's capabilities. The OS you use, the toolchain you have access to, impacts your experience as well.

This X1 matches 92% of a 2022 MB Air's single-core performance and 94% of its multi-core performance (https://browser.geekbench.com/v5/cpu/19092431). I'm happy to wait an extra 100ms for something to compile in order to have a nicer daily experience of the machine and operating system.

I set up and supported 200 X1 Carbons over the past few years.

...but the Gen 10 X1 with out-of-the-box Fedora, the topic of this post, was released just a few months ago.

It's noticeably slower than any Apple Silicon machine

Given how fast it feels, this claim sounded unlikely, so I just ran Geekbench 5, yielding 1769 (single) and 8385 (multi-core):

https://browser.geekbench.com/v5/cpu/19092431

The 2022 MacBook Air gets 1932 and 8919, respectively, so the X1 matches 92% of its single-core performance and 94% of its multi-core performance. You and I may have different definitions of "noticeably slower" and "terribly inadequate."

Fan runs, loudly, if you even breathe on the machine

Ironically, the first time I've heard the fans is running geekbench just now, and even then they were quiet.

Given all this, I think it's unlikely we're talking about the same machine.

I did compare it to the XPS 13 - the XPS looked like a solid machine, but it felt a little cramped to me. I preferred the still-svelte-but-bigger 14" X1.

Another consideration was having a company that cares about Linux running flawlessly, and Red Hat gives their employees Thinkpads. That dogfooding means that if I'm having a problem, it's likely some Red Hat employee is having the same problem, so it ought to be fixed soon :)

Happy to:

Can you navigate with two fingers in a web browser? Yes. I've also been underwhelmed by non-Apple touchpads until using this. I'm not sure how much of the experience is hardware and how much is Fedora 36.

How is text selection? Identical to my Macbook: move to start of selection with pointer finger, press on touchpad with thumb, move to end of selection with pointer, release thumb.

Screen: I'm not sure exactly how to answer this; I have several Macbooks and I agree their screens are nice. I like the Thinkpad's screen more for development (it seems to be less glossy/give better contrast independent of external light) whereas I think the Macbook screens look better at broader angles (for example, a couple of people watching a movie, looking at the screen diagonally).

Battery life: I'll have to run it off charger for more than a day to see when it finally dies. So far I spent one day roaming around without connecting it, during which it was under constant use: programming during the day and streaming at night. Something on the order of 8 hours.

This is a surprising perspective, since we're using web components top-to-bottom to build photoshop on the web, & some of that decision was driven by performance comparisons where web components outperformed react.

It's possible that very naive implementations of web components would render as slowly as you describe - like if you rebuilt the whole DOM tree at every level on every change.

Here is a performance-oriented talk about rendering web components via browser-parsed template literals via Lit (which is how we do it):

https://youtu.be/CJYkwDTaHzY

It's not even interesting that the M1 is "slightly" beaten by a Mac Pro's Xeon, because _nobody is doing raytracing on CPUs._

This is backwards -

Nearly all major raytracing workloads today are done primarily on CPUs: vfx, animated film and tv, etc.

There are several reasons for this, including memory limits and the lack of coherence in both path tracing algorithms and common acceleration structures. GPU-based tracing is currently a small subset of rendering tasks (primarily those with real-time requirements).

As GPU memory increases, GPUs will become more attractive in this space - likely in the next few years.