I'm trying to get my hands on some decently high wattage (100W ideally) incandescent bulbs because it's really been bugging me lately that while I can still focus just fine, I have trouble making out details and some colours in artificial lighting. I've come to the conclusion that there's really no substitute for light generated from heat.
It hugely depends on the quality of the light. Look at CRI (and the newer, better TM-30). Low quality LED lighting is just terrible, the room appears light but colors and details are poor.
It's technically possible to achieve a 100 CRI score with a broad enough range of frequency spikes rather than the continuous range of frequencies you get from incandescent bulbs. So even the best LED bulb isn't going to match incandescent.
I have some LED bulbs at home but I use G9 halogens in either an E14 or an E27 adapter for the places where light quality is important to me. I tried a number of so-called "full spectrum" LED bulbs but I don't find the light they produce quite as satisfying as my halogens.
Philips Warm Glow A19 Medium Dimmable LED Light Bulb 479428, is something I've found. Phillips has been making more lights in the amber range. I really can't stand lights with higher kelvin ratings.
I really like the GE Sun Filled soft white bulbs (not the daylight version). They’re pricey and only 60w equivalent but they’re the closest to incandescent I’ve found.
Finger was only part of the social network. The multi-user aspect of Unix itself combined with standard tools such as who, finger, write, mesg, talk, mail, biff, etc. combined to form a fairly complete text-based social network.
Devices get slower over time due to their operating systems becoming increasingly complex as they're updated. This increased complexity is due to the OS developers taking advantage of the newer models' improved hardware. This leaves owners of older models facing a decision between staying on the older OS version and retaining the current performance vs. updating to the latest version and risk performance degradation. But it's not even that simple. Over time, app developers stop targeting older OS versions, which means you could be stuck with old versions of apps, some of which will refuse to do anything until they're updated.
The way to solve this is for device vendors and their OS developers to simply stop updating the OS in a way that takes advantage of new models' improved hardware because that same code slows down older devices.
I don't think this is a viable or realistic option in 2026/2027. Try to imagine what your own personal reaction would have been when you were 14 years old if 90%+ of your peers had an iphone 17 or equivalent and your parents gave you a flip phone, and tried to ban you from using smartphones.
Why repeat the same argument if it clearly hasn't worked? Do you expect it to suddenly become effective?
Change in behavior can only follow from change in incentives. Parents must be held legally liable if they allow their children access to social media. That means jail time for negligence.
Because according to HN there's no way to force social media companies to not serve children without destroying privacy. That leaves parents who aren't changing their behavior because nothing has incited them to change. Legal liabily is an incentive that changes behavior.
Maybe not everyone agrees that social media causes literal cancer. I mean it’s not great, but it’s not the worst thing on earth, either. It’s clearly become a moral panic at this point.
Supposedly the incentive already exists because parents want their children saved from the harms of facebook and social media. The story is that parents are clamoring for the government to do something about it. I don't think parents really are, or where they are the expectation is that the social media companies will be forced to change their behavior, not that parents will be forced to start parenting their children or be forced to provide a scan of their face and passport every time they do an internet search.
The government has just decided to fall back on "think of the children" as a way to implement more surveillance and control.
The incentive for parents to stop giving their children smartphones does not exist. If it did exist, it would incite parents to perform the action: ie not give their children smartphones.
Incentives incite action. No action. No incentive.
That's not true. Incentives aren't the whole cause of behavior and they aren't the solution to changing it either. That's the same simplistic and flawed mentality that pushes for harsher punishments to deter crime when the evidence shows that doesn't work and that not even death penalty is an effective deterrent. People have several incentives to lose weight, but increasingly they still overeat.
Incentives play a role, you don't want to encourage wrong behaviors certainly, but they're just one factor in determining what people do or don't do. At best, they nudge. Those nudges aren't likely to overcome stronger forces, or even several weaker ones.
> Someone may have a desire or intention to lose weight. But unless they lose the weight they lack incentive.
Here are just some of the incentives overweight people have to lose weight:
They'll look better, to themselves and others. They'll have more clothing options. They'll feel better. They'll be healthier. They'll have drastically lower odds of many future heath problems. They'll live longer which means they can spend more time being with their loved ones.
Those are all incentives. Everyone who is obese has those incentives, even though different individuals may assign different values to them. Even with all those incentives that hasn't stopped the obesity problem. incentives don't incite action, but they can encourage them.
It literally says incite "to determination or action". Given that parents aren't actually taking smart phones away, neither determination nor action are present.
I'll grant you the examples you give incite people to desire to change weight just as negative consequences incite parents to desire that "something should be done," but it doesn't incite them to actually do something.
Describing something as incentive because it incites desire without changing behavior is not exactly what I think of when I think of incentives.
Think of being in the position of trying to come up with incentives for a group of people. Would you call your incentives successful if they created a desire in that group without anyone actually doing anything differently?
You missed the "or has a tendency to incite" part. It's important because incentive doesn't promise a change in action. People can do things even when they have have no incentive to do it. Sometimes people will even do things when they have every incentive not to do it.
If I were going to try to come up with incentives for a group of people, I wouldn't try to create a desire in them. I'd try to give them something they already desired as a reward for doing what I wanted them to do. They'll probably never want to do the thing I want them to do. They might hate doing it. If the incentive is high enough though they just might do it anyway. If my incentives weren't enough to sway them, they'd still be incentives, just ones that were inadequate/ineffective. I wouldn't even be surprised if they failed. Incentives fail to cause changes in behavior all the time.
I've been running Claude Code with --dangerously-skip-permissions in a Docker container for the last month or so, allowing me to get up and stretch my legs while it does its thing. I definitely wouldn't want to run it unsandboxed.
Sandboxing seems like the obvious solution. These tools prompt me to review an absurd number of very complex bash commands where there is realistically no way to carefully review them. I just want to put the thing in a box with the code and let it run any number of commands on the code without prompting.
This is still less safe and less convenient than sandboxing. I want them to be able to run whatever command they want inside the sandbox even if it's traditionally dangerous (overwrites files, etc) because it can't touch anything that matters and I can revert any changes to the code myself.
If anything the only thing you'd have to have reviewed is sandbox escape attempts.
You are right. And the hook is for convenience, not for safety.
Having explicit sandboxes is good, of course. But in addition I also treat my whole computer like a sandbox, it least in the sense that there's no files I would mind if they were overwritten or deleted: you should have backups anyway.
I'd start by identifying all the known boundaries:
52 cards, so each card can be represented by a byte.
Cards are arranged into 4 stacks of up to 13 cards each, 7 columns of up to 13 cards each, and a pile of up to 24 remaining cards. (You don't need two piles of remaining cards.)
That's 167 (4 * 13 + 7 * 13 + 24) bytes for the cards, 12 bytes to store lengths, and 1 byte to store the current index in the pile of remaining cards. It's a fixed number of fixed-length byte arrays and a fixed number of bytes to track lengths and one index.
Not quite. The rightmost one initially has 6 closed cards and 1 revealed card which can be a king, so you can put 12 more cards on top of it, for a total of 6+13 = 19 cards. So I'd make 7 arrays for 20 cards each, just to be safe. Or just use 52-long arrays for every table slot, that too is an option.
> and a pile of up to 24 remaining cards. (You don't need two piles of remaining cards.)
Hm. True, but I'd still probably use two arrays/gap buffer instead of a single array with an index into it.
> 12 bytes to store lengths,
Eh, you can reserve a zero to be a "no card here" value and use NUL-termination instead; the card ranks start up from 1 (the ace) anyhow.
Also, don't forget to track card orientations: some of them are face down, some of them are face up. I usually do it by using the negative numbers for the cards face down :)
All in all, the whole game state fits into a L1 cache of any processor that even has an on-board cache, which is why card games has been around on pretty much every computer ever made.
> Not quite. The rightmost one initially has 6 closed cards and 1 revealed card which can be a king, so you can put 12 more cards on top of it, for a total of 6+13 = 19 cards. So I'd make 7 arrays for 20 cards each, just to be safe. Or just use 52-long arrays for every table slot, that too is an option.
You're right. And I hadn't considered tracking the index of the first revealed card.
Anyway, my point is that you can map out the memory allocation quite easily and it's static and small, so you don't have to worry about malloc and free.
reply