Do regular people care about these things or is this a hn thing?

I find a trackpad (even a Mac one) is absolutely infuriating to use compared to a decent mouse.

Battery life/screens/magsafe I'm plugged into a dock 99% of the time so it's irrelevant, but when forced to occasionally, the ergonomics of looking down at a single small 1x in screen is just terrible if doing it for hours and also makes my back feel horrible.

I might be weird but actively prefer the trackpad to keyboard and mouse as I can let my fingers rest on the keyboard at all times and use the thumb when needed to touch the excellent trackpad. That’s better than removing the whole hand to grab the mouse just to click something.

My home setup has both a trackpad and mouse (and a separate keyboard). I like them both. In practice I use 65% mouse and 35% trackpad I think. Trackpad is great for horizontal (or 2d) scrolling and gestures. Mouse has better ergonomics for accurate pointing, and is more natural in some apps (eg KiCAD).

I agree. Trackpads also come with gesture support for things like switching between windows which I found difficult to live without. Unfortunately it's not very ergonomic to use a laptop with it's trackpad when you're using multiple screens.

It ignores my scroll wheel most of the time if I try to scroll multiple times in a row.

The scroll is delayed significantly from when I scroll to when it actually scrolls.

The amount scrolled is inconsistent, sometimes it scrolls a very slowly a tiny amount because the page doesn't fit on the screen by an unknown tiny fraction, but if I scroll again because it is scrolling both slowly and with delay it now scrolls an entire page.

If I want to scroll past one of the demos I have to wait

If I drag the scroll bar on the side slightly it often snaps backwards.

It feels like I'm interacting with a phone/tablet screen on a computer, there's a reason why windows 8 failed.

10k in 2hrs is 1.5 lines of code per second for 2 hours straight without spending any time to make comments, think about what the code is doing, etc.

In pre-ai era that is just skimming and trusting the person who wrote it or the code changes are largely auto-generated or there exists an exceedingly simple test suite that is incredibly verbose.

Post-ai you are ruining your code base, I probably have to spend 3-5x longer reviewing ai generated code, the code they write tends to be too verbose, mediocre, filled with subtle bugs, adds unnecessary comments, etc. If someone gives me 10k loc pr it's a sure thing they've just let the ai run loose and I'd just tell them what they need to change in general terms instead of wasting days of my time reviewing junk.

> Post-ai you are ruining your code base

if a pr is bad, i will reject it. that's the point of code review.

The point is that there is a 0% chance you can meaningfully understand the impact and consequences of what a 10k line change is doing in a couple hour review, so there’s no way for you to know if it’s “bad” in any sense other than it’s so awful that it’s obvious on a skim (which is what 10k lines in a couple hours is).

I find difficult to know how serious the issue is, if it is even an issue.

LLM constantly confidently giving me this same sounding script with a "the root cause" and how it "is simple" while being completely incorrect.

Most of them involve very weird and unlikely scenarios and bad security practices or access to the ffmpeg binaries and being allowed to run arbitrary commands at an elevated permission.

In and of itself there's not a massive issue from what I can see, they're entry vectors that can lead to worse situations.

That's not to say they're not serious but if a Russian hacking group is using one of them it's in conjunction with other exploits or security flaws. Which is common in practice when it comes to decoding.

Its 21 issues. And they've been human validated, as far as I can tell.

Every decision has trade-offs. The best design is often the simplest, which can mean combining layers/responsibility in small or throw away projects.

The step above that is to make the simplest design that is extendable.

Often newbies doing "Best practice" results in more code that is overly complex, it splits understanding across too many functions and tries to create too many "reusable" functions that often mean the architecture is often extendable in useless ways but harder to extend when you actually need to do it.

You can usually notice when interacting with these battle scarred pieces of code, if the author is still there there is usually a story for why things are the way they are.

Even if you fixed the initialized data problem, this code is still a bug waiting to happen. It should be a single bool in the struct to handle the state for the function as there are only two states that actually make sense.

succeeded = true; error = true; //This makes no sense

succeeded = false; error = false; //This makes no sense

Otherwise if I'm checking a response, I am generally going to check just "succeeded" or "error" and miss one of the two above states that "shouldn't happen", or if I check both it's both a lot of awkward extra code and I'm left with trying to output an error for a state that again makes no sense.

It happens often when "error" field is not a bool, but a string, aka error_message. Could be empty string, or _null_, or even _undefined_ if we're in JS.

Then the obvious question why do we need _succeeded_ at all, if we can always check for _error_. Sometimes it can be useful, when the server doesn't know itself if the operation is succeeded (e.g. an IO/database operation timed out), so it might be succeeded, but should also show an error message to user.

Another possibility if the succeeded is not a bool, but, say, "succeeded_at" timestamp. In general, I noticed that almost always any boolean value in database can be replaced with a timestamp or an error code.

Honestly I gave up trying to support apple products a while ago - the fact that iOS and Mac lock the browser version to the os version makes it such a royal pain in the ass to support.

To be fair, the macOS Safari is not tied to the OS. Don't remember if it ever was, but it def isn't anymore then.

Unfortunately it was and still is. https://en.wikipedia.org/wiki/Safari_(web_browser)#Version_c....

MacOs is slightly more forgiving in that the last 2 versions can get the latest safari. However, people tend to keep a computer a lot longer than a phone and many don't or can't update macOS, so it's not much better.

It's absolutely amazing the degree to which Apple has recapitulated the Internet Explorer debacle of thirty years ago.

Is his build even possible today in a laptop?

In a desktop, you would need a top of the line threadripper for that 256GB/s of memory bandwidth.

Consumer grade Zen 5 desktops reach only about 80GB/s in real world testing, with a theoretical max of slightly over 100GB/s.

AMD Strix Halo (a consumer mobile processor) has theoretical support for 256GB/s of memory bandwidth (quad-channel, 8000 MT/s LPDDR5X, must be soldered, supports 128GB at most).

The memory is shared for the GPU, so you should probably compare with desktop GPU, so 1-2TB/s.

Yes. OneXfly apex. Amd 395+, oled panel.

I think the point of him making his own laptop is that he would fix all those software problems.

> - when closing the lid and walking to the coffee shop will the battery be dead before you finish your coffee? probably

Why probably? Going to sleep on lid close is common enough, it's even the default in all OSes/DEs. If you turn off sleep-on-close and drain the battery, that's on you.

> - is the text in your "stunning oled" going to be rendered correctly in linux? probably not

> - will the wifi chip work in linux? maybe

> - will all the ports work/behave? probably not

These seem like odd things to doubt, when Framework has a perfectly working system for Linux and has been doing it for years. No hardware in their systems is unsupported in Linux.

Notably the critique of Framework in the original blog post does not offer these doubts. They are focused instead on the hardware design and tradeoffs between upgradability and uniform bodies. Those are real tradeoffs and Framework cannot solve them all without abandoning the upgradability part.

High end machines which can easily pull 100W+ are just bad in general for portability - running at max will last less than 1Hr, will the sleep mode actually work reliably and not drain battery? - this is an issue in most OSes/laptops. Will video playback in the browser not be properly hardware accelerated and drain the battery super fast? yes linux has issues here.

Framework were explicitly ruled out, so: Integrated Oled - you really want some integration, If you can't set the brightness, goodbye lifespan, oled also have many different subpixel layouts which can make the text blurry/fringe, maybe you wont notice but then why buy an oled in the first place for work? While a monitor will definitely have pixel shift/burn in protection built in, if integrating a panel into the laptop without putting in any work, that support might not come out of the box

Even if it was a framework, everything is distro specific, but I think you only need to know that a "dock megathread" exists to realise that "perfectly working" is a stretch and a lot of people have hardware they can't connect and doesn't work.

That said if I was to buy a laptop - a mid end framework I just do the basics with would probably be great.

Doing that will increase input latency, not decrease it.

There are many tick rates that happen at the same time in a game, but generally grabbing the latest input at the last possible moment before updating the camera position/rotation is the best way to reduce latency.

It doesn't matter if you're processing input at 1000hz if the rendered output is going to have 16ms of latency embedded in it. If you can render the game in 1ms then the image generated has 1ms of latency embedded in to it.

In a magical ideal world if you know how long a frame is going to take to render, you could schedule it to execute at a specific time to minimise input latency, but it introduces a lot of other problems like both being very vulnerable to jitter and also software scheduling is jittery.