Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
marcan_42
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
12 ms
·
61.
▲
by
marcan_42
5y ago
I've lived for 8 years in Japan and haven't had a single incident of xenophobia at a konbini. Though I will say I got a chuckle out of the ojisan who threw a perfect Microwaveでwarmしますか? at me once :-)
62.
▲
by
marcan_42
5y ago
Compiling is CPU-bound and doesn't really bottleneck on anything that libc is involved with other than the allocator, so unless musl's allocator is comically slower than glib's, chances are it's just -Os.
63.
▲
by
marcan_42
5y ago
Definitely still buggy; I know for a fact it still oopses when certain USB things go wrong, which is by definition a bug.
64.
▲
by
marcan_42
5y ago
The device is buggy and the kernel is buggy. The device is buggy because it did something stupid; the kernel is buggy because it crashed in response. That's two independent bugs. Sometimes it isn't even buggy devices, just dev
65.
▲
by
marcan_42
5y ago
> I’d be willing to bet my life that the kernel’s more than a decade old and globally deployed XHCI implementation is not the cause of his USB issues. I wouldn't, because I've found and fixed bugs in the kernel's xHCI impl
66.
▲
by
marcan_42
5y ago
I don't know how you plan to tell apart kernel xHCI driver bugs from xHCI controller bugs with usbmon, which has nothing to do with the xHCI layer. It's at a higher layer. It doesn't show you anything related to xHCI internal
67.
▲
by
marcan_42
5y ago
Audio CDs do have framing information (in the subchannel). However, the subchannel has no error correction (only basic error detection), so the CD player has to interpolate across subchannel errors (which are normal and common) to figure ou
68.
▲
by
marcan_42
5y ago
It won't, because you can't know if the misbehavior is caused by a device or the host controller when you're looking behind the host controller. Everything you see in usbmon is influenced by both. And besides, a malfunctionin
69.
▲
by
marcan_42
5y ago
You cannot diagnose/debug host controller hardware/driver issues with usbmon. It does not work at a low enough layer. It's only good for debugging issues with downstream devices. You also cannot tell whether certain problems
70.
▲
by
marcan_42
5y ago
All of them. The CPU graph is pegged for most of the compilation.
71.
▲
by
marcan_42
5y ago
I've been saying 4x M1 Max is not a thing and never will be a thing ever since the week I got my M1 Max and saw that the IRQ controller was only instantiated to support 2 dies, but everyone kept parroting that nonsense the Bloomberg re
72.
▲
by
marcan_42
5y ago
My 1st gen 16 core Threadripper is barely faster than an M1 Pro/Max at kernel builds, so a 64 core TR3 should handily double the M1 Ultra performance. But you know, I'm still happy to double my current build perf in a small box
73.
▲
by
marcan_42
5y ago
Better entropy coding. TL;DR JPEG and other "lossy" compression formats are two steps: the lossy step and a lossless step like ZIP. You keep the lossy step as-is and improve the lossless step.
74.
▲
by
marcan_42
5y ago
A single USB xHCI controller is not bottlenecked to 480Mbps globally, since the multiple ports aren't actually sharing a 2.0 physical layer. The "root hub" isn't like a normal hub in that sense. So you don't need a
75.
▲
by
marcan_42
5y ago
> For a while, I do not believe the USB transaction translator[1] was not totally commonplace: I remember articles specifically highlighting which usb2 hubs had this feature. You are misremembering. All 2.0 hubs have TTs. The question is
76.
▲
by
marcan_42
5y ago
And the reason why that doesn't and can't work with USB2 is because, unlike Ethernet, USB is extremely closely tied to its physical layer and you cannot actually buffer and switch USB packets at all (without cooperation from at le
77.
▲
by
marcan_42
5y ago
What USB-IF should have done is specify USB3 to USB2 and USB4 to USB2 transaction translation, like they did for USB2->USB1. It doesn't mean they need to get rid of the USB2 wires, but it means utilizing the 5Gbps+ USB3 bandwidth
78.
▲
by
marcan_42
5y ago
That's better , because with the PCIe layer and a real host controller on the dock/hub, you finally get 480Mbps per port for USB downstream devices. Thunderbolt hubs are the only standards-compliant way to do this, today. USB4
79.
▲
by
marcan_42
5y ago
Both of those ways are what I said, done in different ways. PCI-in-USB3 is not a standard protocol. No matter what you do, there is no way to make it work within standard class protocols only. > There's two other ways. One is to use
80.
▲
by
marcan_42
5y ago
It is impossible to implement that. The USB standard for some inexplicable reason refused to specify USB 3 to USB 2 transaction translation. That's why it doesn't exist. There is no way to implement it that works as you would expe
81.
▲
by
marcan_42
5y ago
> with the replacement of the copyright headers being among the largest changes in some cases I'm surprised they let that fly. Removing existing copyright headers from code you copy wholesale is a very bad idea, even if the license
82.
▲
by
marcan_42
5y ago
Yeah, I was wondering where the heck 2ms disk seek times came from. That's not a thing and will never be a thing; disks only spin so fast, and nobody even uses >7200RPM drives any more (because we've all moved to SSDs instead).
83.
▲
by
marcan_42
5y ago
Yup, all stars other than the Sun are below our ability to resolve as anything other than a point, so they do indeed look dimmer than the Sun to us. The inverse square law always applies, but it relates to the total amount of light receiv
84.
▲
by
marcan_42
5y ago
> If we reverse the situation the analysis is clearly flawed. The Sun is not a particularly bright star in an absolute sense, but it's extremely bright to us. If you moved it a few hundred AU farther away, it would become difficult
85.
▲
by
marcan_42
5y ago
It's not about a shifter, it's about determining instruction boundaries. With variable-length instructions the next instruction start depends on the previous one, making it an inherently serial process. Working around that to deco
86.
▲
by
marcan_42
5y ago
But it does. x86 is hell to decode in parallel, because it's variable length (and in a complex way), so Intel can't build CPUs that keep a wide pipeline fed with instructions efficiently like Apple can, with the 8-wide decoder in
87.
▲
by
marcan_42
5y ago
You argued, specifically, that, > You're modifying the program whether you've touched any files containing plain text source code or not. And that is just not how copyright works. (Separately, if you ever find yourself linking
88.
▲
by
marcan_42
5y ago
Double the distance, you get 1/4 the light. Double the distance, you get 1/4 the solid angle. The surface brightness of the object in your field of view therefore stays constant.
89.
▲
by
marcan_42
5y ago
It does not. The copyrighted work is the code for the software, and making modifications means modifying the copyrighted software. Copyright has no notion of "modification" in the sense of changing the final behavior. It's st
90.
▲
by
marcan_42
5y ago
I'm not relying on the contractual barrier, I'm relying on the interpretation of the clause as applying strictly to the behavior of the program as designed and embodied in the source code, and arguing that there is no moral requir
More ›