I'm curious about a system where capital gains are 100% for the first... I don't know, let's say a month. Then you ramp down over the course of the next year until it matches the regular income tax rate. I'm less concerned about the specific time periods than I am about the idea that it would be beneficial to society to have our financial systems encourage long-term thinking.
Exactly, the headline sort of paradoxically reflects the desire for news, and not news itself.
But still, the actual stock market behavior right now is PROBABLY (!!) more reflective of random motion than it is of a fundamental shift in investor behavior.
"My attention is a limited resource. In order to prove that you're a serious human, please donate exactly $157.42 to the Rust maintainers fund and paste the receipt link here".
> With the HDMI 2.2 spec announced at CES 2025 and its official release scheduled for later this year, 8K displays will likely become more common thanks to the doubled (96 Gbps) bandwidth.
Uncompressed, absolutely we need another generation bump with over 128Gbps for 8K@120Hz with HDR. But with DSC HDMI 2.1 and the more recent DisplayPort 2.0 standards is possible, but support isn't quite there yet.
Nvidia quotes 8K@165Hz over DP for their latest generation. AMD has demoed 8K@120hz over HDMI but not on a consumer display yet.
Is it actually good for productivity? The curve isn’t too aggressive? Could you, e.g. stack 3 independent windows and use all 3? Or you kind of give up on the leftmost / rightmost edges ?
I think window managers these days do a better job on 3 monitors than on a single one that could have the same area.
With an ultra wide you lose the screen concept for managing area and it gets awful because you lose grouping windows on different screens, picking per-monitor workspaces, moving windows across screens.
Either monitors need to present themselves as multiple screens, or window managers need to come up with virtual screens to regain the much needed screen abstraction.
I prefer 3 monitors because it eases window management while being cheaper. For gaming I only need one 240Hz+ monitor and for Lan parties I only take that one.
Although for sim racing I've been thinking about getting a single ultra wide and high refresh rate monitor, but I'd probably go for a dedicated setup with a seat, monitor and speakers. It gets pricey, but cheaper than crashing IRL.
Just don't try putting something convenient in between, at least that's what my adventures in TB4 taught me: displayport from a TB port works fine, even when DP goes to a multiscreen daisychain and the TB does PD to the laptop on the side, but try multiscreen through a hub and all bets are off. I think it's the hubs overheating and I've seen that even on just 2x FHD (Ok, that one was on a cheap non-TB hub, but I also got two certified TB4 hub hubs to fail serving 2x "2.5k" (2560x1600). And those hubs are expensive, I believe that they all run the same Intel chipset.
That would require monitors supporting daisy chain in the first place and I never had any problems with them anyways. Likely related to not using a full on hub but a minimalistic dongle with a DP outlet, a PD inlet and a USB outlet (which then goes to a USB hub switch managing access to simple hubs serving all those low bandwidth peripherals like the mouse).
The failing hubs were either driving cheap office displays connected through HDMI or high resolution mobile displays connected through USB-C. Few of those support anything like daisy chaining or at least simple PD passthrough so that you can use the same port for driving the display and powering the laptop, and I absolutely do want dual mobile displays. Even if only so that I can carry them screen to screen for mutual protection of the glass.
I wouldn't hold my breath. Competing models seem to top out around 120 Hz but at lower resolutions. I don't imagine there's a universal push for higher refresh rates in this segment anyway. My calibrated displays run at 60 Hz, and I'm happy with that. Photos don't really move much, y'know.
In one of James Gosling's talks he tells a funny story about the origin of this design decision. He went around the office at Sun and gave a bunch of seasoned C programmers a written assessment on signed/unsigned integer behaviors. They all got horrible scores, so he decided the feature would be too complicated for a non-systems programming language.
Non-systems languages still need to interact with systems languages, over the network or directly. The lack of unsigned types makes this way more painful and error-prone than necessary.
It’s rare I have to do bit math but it’s so INCREDIBLY frustrating because you have to do everything while the values are signed.
It is amazing they haven’t made a special type for that. I get they don’t want to make unsigned primitives, though I disagree, but at least makes something that makes this stuff possible without causing headaches.
Sometimes I'd like to have unsigned types too, but supporting it would actually make things more complicated overall. The main problem is the interaction between signed and unsigned types. If you call a method which returns an unsigned int, how do you safely pass it to a method which accepts a signed int? Or vice versa?
Having more type conversion headaches is a worse problem than having to use `& 0xff` masks when doing less-common, low-level operations.
This adds an extra level of friction that doesn't happen when the set of primitive types is small and simple. When everyone agrees what an int is, it can be freely passed around without having to perform special conversions and deal with errors.
When trying to adapt a long to an int, the usual pattern is to overload the necessary methods to work with longs. Following the same pattern for uint/int conversions, the safe option is to work with longs, since it eliminates the possibility of having any conversion errors.
Now if we're taking about signed and unsigned 64-bit values, there's no 128-bit value to upgrade to. Personally, I've never had this issue considering that 63 bits of integer precision is massive. Unsigned longs don't seem that critical.
I think the only answer would be you can’t interact directly with signed stuff. “new uint(42)” or “ulong.valueOf(795364)” or “myUValue.tryToInt()” or something.
Of course if you’re gonna have that much friction it becomes questionable how useful the whole thing is.
It’s just my personal pain point. Like I said I haven’t had to do it much but when I have it’s about the most frustrating thing I’ve ever done in Java.
I don't know about gifted programs, but anything that separates kids who don't want to learn from those who do is a good thing; far to much time is wasted in America's schools catering to bad behavior.
This. Frankly, it is aggravating if not depressing that it is somehow issue that should be considered at a national level. It is an issue that it even is an issue.
This isn't really that different to GWT, which Google has been scaling for a long time. My knowledge is a little outdated, however more complex applications had a "UI" server component which talked to multiple "API" backend components, doing internal load balancing between them.
Architecturally I don't think it makes sense to support this in a load balancer, you instead want to pass back a "cost" or outright decisions to your load balancing layer.
Also note the "batch-pipelining" example is just a node.js client; this already supports not just browsers as clients, so you could always add another layer of abstraction (the "fundamental theorem of software engineering").
Does anyone know what it looks like when you use a line scan camera to take a picture of the landscape from a moving car or train? I suspect the parallax produces some interesting distortions.
Sorry for the purple trees. The camera is sensitive to near infrared, in which trees are highly reflective, and I haven't taken any trains since buying an IR cut filter. Some of these also have dropped frames and other artifacts.
Because i can produce 5 clean, properly sized commits in the time it takes to do one round of reviews, so they have to be stacked. It's important that the CI run independently on each commit, and each commit builds on the work of the previous one.
I've had a lot of success writing driver test cases against the hardware's RTL running in a simulation environment like verilator. Quick to setup and very accurate, the only downside is the time it takes to run.
And if you want to spend the time to write a faster "expensive mock" in software, you can run your tests in a "side-by-side" environment to fix any differences (including timing) between the implementations.
It's cool to learn about Verilator: I've been proposing our HW teams give us the simulations based on their HW design for us to target with SW, but I am so out of the loop on HW development, that I can't push them in this direction (because they'll just give me: "that's interesting, but it's hard", which frustrates me to no end).
Can you perhaps do a write-up of what you've done and how "slow" it was, and if you've got ideas to make it faster?
The hardest part is toolchains, for two reasons. First, Verilator doesn't have complete SV language support, although it's gotten better. Second, hardware has a tendency to accumulate some of the most contorted build systems I've ever seen and most hardware engineers don't actually know how to extricate it.
Once it's actually successfully run through Verilator, it's a C++ interface. Very easy to integrate if your sim already has a notion of "clock tick."
