chaorace

Just spitballing a high-level implementation:

1. Color correct for the CMYK printing process

2. Load image as a pixel matrix

3. Unwrap pixel matrix into a pixel vector

4. Convert the pixel vector to HSV representation

5. Group each pixel into a palette slot by plugging the H/S dimensions into K-means with 32 as the target (ignoring L for clustering to account for scanlines/flicker)

6. For each palette slot, calculate the "true" HSV value by taking the group's median H/S values and the mean V value

7. Convert HSV representation to 12-bit RGB colorspace

FWIW: lithium-ion was also expensive chemistry. If the promise matches the reality, supply chains will eventually realign to the point where consumer applications become feasible.

I think it's more about being against the principle of piping potentially sensitive data to any third party.

True, OpenAI doesn't have any real motivation to randomly pluck your data and decide to do something horrible to you with it... but they could. More importantly, circumstances can and will change as time goes on. If your logs change hands as part of a buyout or cyberattack, you'll have no recourse.

Just FYI: this is referring to USB charging stations, not EV stations.

This advice has been standard in cybersecurity training for a long time now and frankly I'm surprised that this is the first time the FBI has felt the need to issue an advisory on the subject.

The solution is simple: downweight all content which generates engagement of any kind

> Could it maybe work the other way, start to make the WWE more real?

That would be a tragic mistake for everyone involved. People like being in on the joke when John Cena, a grown man costumed in neon green, runs around the square stage whilst pretending to be invisible. It would ruin the fun if his opponent unceremoniously dropkicked him in the solar plexus.

Python has the misfortune of competing against JS in this arena, which just so happens to have the most obsessively optimized JIT ever.

> An insanely helpful community. Tons of knowledge out there for getting it to do anything you can dream of.

This may actually be one of the biggest lasting impacts of the Steam Deck. It puts a lot of enthusiasts with a common interest on a highly reproducible and officially supported configuration. If a game doesn't work, you can file a bug with Valve on Github about it and most of the time it'll be fixed within a week. If the system itself is misbehaving, you can feel safe knowing that there are thousands of others on the exact same configuration.

Just two weeks ago, I had an issue with the system resuming into a blacked-out screen, so I vaguely Googled the symptoms and "Steam Deck", which led me to a Reddit thread with oodles of people experiencing the same issue[1]. Someone said it was a bug related to the new customizable boot animation feature -- I turned the feature off and I could go on with my day without even opening a single log file!

[1]: https://old.reddit.com/r/SteamDeck/comments/11ubgfl/latest_u...

Apex Legends uses Epic Anti-Cheat ("EAC"). Valve collaborated with Epic to get EAC functional in Wine back in September[1]. This Wine support is an opt-in flag at build-time, so many games using EAC still remain incompatible (e.g.: Fortnite). Apex players asked for EAC-on-Wine to be enabled and the developers obliged by checking the checkbox.

The reasons for why this is opt-in only are not public knowledge, but I wouldn't be surprised if this was some sort of special reduced-security mode. The APIs available to EAC-on-Wine are more-or-less a strict subset of those available to EAC-on-Windows, after all. FWIW: I don't think any Wine-exclusive exploits have ever been found in the wild.

[1]: https://dev.epicgames.com/en-US/news/epic-online-services-la...

Food for thought: with minimal processing, rice can be turned into a consumer-ready foodstuff that keeps for years without refridgeration. The plant itself produces a greater yield per acre than other grains and, when dried, packs an incredible 350 calories per 100 grams.

This is all to say that rice demands less farmland development, is more fuel efficient to farm, more fuel efficient to process, more fuel efficient to transport/store, and less prone to wastage. I'm not a climate scientist, but I suspect these factors balance out the calculus somewhat.

Perhaps more importantly: rice is cheap, delicious, and culturally important. It's simply not going away as long as people continue to live on this planet. That's not to say that we should consider the methane footprint to be an empty trifle, of course. It's absolutely still a problem to be solved.

One possible solution would the GMO route -- China is uniquely positioned here, since they have both the required research infrastructure and economic command to make it happen and get adopted. The promise of this is already starting to be realized with China's recent success in making truly perennial rice a commercial reality[1][2]

[1]: https://www.nature.com/articles/s41893-022-00997-3

[2]: By the way, I'm not a China plant and I'll prove it: Taiwan deserves international recognition as a free and independent country. China needs to stop perpetrating the Uyghur genocide. China needs to free Tibet and cease their domination of Tibetan Buddhism. China needs to rescind the national security law and restore democracy to Hong Kong.

> What widgets are you referring to that you found to have leaks?

I'll cite myself here: https://github.com/streetturtle/awesome-wm-widgets/issues/11...

Here's another affected library [1]: https://github.com/deficient/volume-control

I've had similar issues wherever GTK interacts with awful.spawn. Basically: glib (GTK) + awful.spawn.easy_async + polling = extremely leak-prone. This is a very common pattern in community awesomewm widgets.

[1]: No bug under the main repo because they're considering it as a framework bug. See here for discussion: https://github.com/awesomeWM/awesome/issues/3584#issuecommen...

> I've been using it for several years at this point and haven't encountered any memory leaks (it already uses so little).

It's the community widgets that tend to have memory leak problems, not the core package. As mentioned, this seems to be a quirk in how Lua and GTK interact (many community widgets use GTK).

> Sure, stacks are not supported out of the box, but it is an easy thing to add if you want it. I think they are entirely consistent and bug free, as much as anything else - some specific apps might have an issue but you can also write a rule to deal with them as needed.

They're not. I've used all of them. It's not an issue of rules, it's an issue of the core UI framework fighting against the hacked-on stacking implementation. There are design-time assumptions baked into the AwesomeWM layout engine that cannot be worked around using the API. You'll just have to take my word for it when I tell you that I've tried very hard and for a very long time.

> I'll take a completely customizable lightweight interface that I can tailor every aspect of every time, especially when it's so user friendly (for what it is).

I wouldn't really call AwesomeWM exceptionally user-friendly. The docs are good. The API is good. It's developer-friendly, certainly, but that's as far as the ease-of-use goes.

Counter-review: the level of control is unmatched, but it's a little too extreme, I feel. Even something as simple as a volume widget isn't included OoB. Yes, there are libraries of widgets out there, but not many -- and not always the best quality (memory leaks are unfortunately common, seems to be a screwy lua/GTK interaction).

More importantly: the core framework just outright omits many of the core features that I've come to expect in tiling WMs. There's no support for i3-style window stacks, for example; I've tried several community solutions, but they're all trapped on a too-high abstraction layer and inevitably end up fighting with the WM in ways that you simply never need to deal with in first-class implementations.

All in all, I'm planning on returning to i3wm. For me, it's a bigger struggle to try building up a usable environment from scratch than it is to start with a solid foundation and then replace the undesirable components (i3bar => polybar, bindsym => sxhkd). AwesomeWM is very fun to work with thanks to the great APIs and documentation, but I can only wholeheartedly recommend it if you need absolute and total power over the UI, since that's AwesomeWMs whole schtick.

If you folks and Jack manage to make the OLKB module a reality, you'll have me vendorlocked for life. I think I'd go so far as buying 3 of those modules just to be extra sure that I'm set with replacement parts.

Uh... completely unrelated question: have you laid out any plans regarding module backcompatibility on future boards?

> On their github they reference a related project called "HuggingFace"

Quick jargon literacy boost: "HuggingFace" is a platform tailored to hosting and sharing ML repositories -- like Github for AI. The parent company, "Hugging Face", is also in and of itself a major contributor to several AI research projects & tooling.

Ironically, they still managed to hit a namespace collision... albeit self-inflicted.

Is it really the same experience, though? In newsstand publications, you can swipe up/down to skip articles and there's a special 2-pane ToC that lets you navigate by sections. I'm not even sure if the epub format has the capability to provide magazine-specific integrations like these.

> in the medieval and early modern era the wealthy had many more surviving kids than the poor

Per Figure 2 of Fertility trends by social status by Vergard Skirbekk[1], we see that -- globally -- high social class begins to exert an overall negative pressure pressure on fertility relative to the lower classes as early as the start of the 1700s. So, yes, "Always" was a wrong description on my part, as we do see the opposite relationship during the early premodern and late medieval periods.

It would have been more accurate of me to say something like: "historically, we see that the rich and educated upper echelons of society have apparently struggled with fertility for hundreds of years".

> contraceptives did not exist

Contraceptives did indeed exist. The much fabled Silphium springs to mind. Those of higher social class would certainly have had better access to experienced practitioners and the various abortifacient concoctions which might have currently been in fashion.

> physical survival was a challenge [...] so the wealthy were the ones who could afford to keep their kids alive and healthy in large number

On the other hand... there were much stronger incentives for agrarian family units to have children. More children meant more labor. More labor meant more land productivity. Agricultural success often went hand-in-hand with copious production of children.

[1]: https://www.demographic-research.org/volumes/vol18/5/

Recursion is recursion, obviously.

It would only have explanatory value if you could prove that "intelligent" people have become relatively less fertile over time, compared to the population as a whole.

Of course, historically, we see that the rich and educated upper echelons of society have apparently always struggled with fertility. There's also the nagging issue that even highly stratified societies aren't that stable on evolutionary timescales.

As a Linux user, I've given up on alternative Spotify clients. The official client sucks... but at least it works consistently and has full feature support.

Instead of replacing it, I've resolved to minimize my interaction with the client as much as possible via rofi[1] and media shortcuts.

[1]: https://github.com/davidborzek/spofi

Skipping to the good stuff from the patch notes:

> Wangyang and Arjan reported a bottleneck in the networking code related to struct dst_entry::__refcnt. Performance tanks massively when concurrency on a dst_entry increases.

> This happens when there are a large amount of connections to or from the same IP address. The memtier benchmark when run on the same host as memcached amplifies this massively. But even over real network connections this issue can be observed at an obviously smaller scale (due to the network bandwith limitations in my setup, i.e. 1Gb).

Basically, processes that produce a lot of threads (i.e.: 100+) suffer performance degradation. This impacted network performance by up to 5% on 1 Gb/s connections and showed up to 3.2x performance degradation in synthetic benchmarks.

Independent testing verifies these improvements in the Memcached benchmark. Simulating a more realistic workload using Cockroach DB shows a more modest performance improvement of ~5% in terms of ops/s.

It's a persona that the system_prompt.txt[1] file defines for ChatGPT to inhabit as part of the starting prompt:

> We are a in a chatroom with 3 users. 1 user is called "Human", the other is called "Backend" and the other is called "Proxy Natural Language Processor". I will type what "Human" says and what "Backend" replies. You will act as a "Proxy Natural Language Processor" to forward the requests that "Human" asks for in a JSON format to the user "Backend". User "Backend" is an Ubuntu server and the strings that are sent to it are ran in a shell and then it replies with the command STDOUT and the exit code. [...]

[1]: https://raw.githubusercontent.com/rareranger/chatgpt-linux-a...

It depends on the domain. For example, recursion can be extremely useful when processing a tree of data.

The thing that really irks me is that the generator pattern doesn't have to be an OO-first feature. Observable streams[1] work with the same basic foundation and those are awesome for FP. It's really frustrating that standard libraries are so eager to adopt generators without taking that last step into supporting functional stream consumption.

[1]: https://reactivex.io/

Case in point: Tail Call Optimization has been part of the JS spec since ES6, but remains completely unimplemented in all mainstream browsers/engines besides Safari[1]. For all but the most predictable inputs, you're pretty much forced to use loops due to potential overflows in situations where recursion might otherwise be preferable.

More fuel for the pyre: async Iterables cannot be consumed as a piped stream. You must use the for await construct, which is a shame considering the FP niceties that the Array type already provides for more traditional lists. Once again, one is forced by the API to use an imperative construct unless they specifically want to invite trouble by converting it into an Array (... and potentially choking in the process)

[1]: https://kangax.github.io/compat-table/es6/

I think the core problem is that it's very hard to create an AI that's impressionable enough to internalize a conversation without being so impressionable as to turn into putty in a skilled user's hands.

If you ask me, the best solution to the problem probably involves introducing a second, separate LLM supervisor agent. One that is much less impressionable and specifically trained to recognize and throw out dangerous inputs before the chat agent's precious little mind is tainted.

I've said the same thing in the past about curbing the chat agent's tendency towards hostile responses. Instead of training a nicer agent, you should train an output supervisor agent that recognizes bad sentiment, throws out the response, then tells the chat agent to "try again, but be nicer this time".

While it's very civil of you to wish recovery upon LastPass, I don't really think the product is deserving of redemption. This is not the first major incident and it demonstrates little growth in relation to prior breaches. The world as a whole would probably be better off if LastPass were to breathe its last.

> there are generally two necessary aspects to "getting good": game knowledge and understanding your opponent

At the risk of overcomplicating an astute observation, I'd say that there are actually three aspects: game knowledge, maneuvering, and metagaming. That is to say that the ability to understand your opponent is fundamentally separate from one's ability to effectively foil them.

Iceworld embodies the platonic ideal of a maneuvering test by massively compressesing the total number of possible gamestates into a 3x3 grid of sightlines. The map itself isn't exactly a masterstroke, but it's nonetheless extremely impressive in the way that it manages to avoid collapsing into degenerate gamestates after jettisoning so much complexity.

If anything, this strikes me as a person who just really didn't like what they were doing and eventually imploded along their own personal fault-lines. Not to be overly reductive of their psychosis, of course -- one cannot disentangle the neurological from the psychological and so the way things shook out is hardly a matter of personal responsibility or playing blame.

This is all to say that they have my sympathy... but also to kind of disagree with their premise. Truthfully, the "best" bad programmers never get so far as imploding. They simply manage to sabotage everything they touch while being none the wiser. They smoothly redirect blame whenever it comes their way without even consciously thinking about it, because they truthfully believe that they are in the clear.

It's all about hardware. I've addressed it quite well with a three-pronged approach:

1. Motorized standing desk - typing from varying postures keeps strain spread out

2. Kensington trackball mouse - less hand sweeping / temptation to drags wrist on table

3. Ortholinear "Planck" keyboard - modifier keys accessible via thumb and programmable layers more generally can completely eliminate painful hand poses and keep fingers on the home-row