tkfu

What's with the creepy sexualizing of every woman he encounters?

The argument is that LLMs are making unikernels easier to work with, and having a whole OS stack leaves a big attack surface, as demonstrated by the scads of LPEs and other vulns we've been seeing in Linux over the past year+, right?

But you know what else is easier with LLMs? Properly hardening your Linux system. "Patch every week" is the recommendation from upstream because the kernel security team has to consider every possible deployment configuration and environment. If you implement all the KSPP recommendations, use a config and kernel command line that makes sense for your actual application, and use a properly configured MAC LSM, you would not have been affected by any of the big blockbuster vulns of the last year.

So if you can tell an LLM to port a library in a loop and feel confident in the results, surely you can feel equally confident telling the LLM to harden your Linux environment.

n.b.: I am not endorsing the idea that just throwing LLMs at security problems is actually a good answer, I'm just saying that the case the article makes isn't actually comparing like for like.

> Pay to buy these homeowners out of their single family and convert the land to multifamily.

But that's what the market is already doing? In your example from above, you can take a $400,000 windfall and move somewhere else, or take out a mortgage against that $400,000 of new equity to pay your taxes and still come out waaaaay ahead. I don't understand your characterization of a second mortgage as "taking the house away" at all.

> property taxes and HOA fees alone

I feel like HOA fees have to be doing most of the damage there. AFAIK the highest property taxes in the US still top out around 2%, so for a "multiple thousands per month" property tax bill it has to be a house worth more than $1.2 million. I'm not sure what the line is for what level of housing expense is reasonable for society to subsidize housing security for, but I'm pretty sure $1.2 million is well past it.

This reads as classic shilling to me. There are companies that sponsor the industry association, who have a strong interest in people choosing to treat with their products. One of those companies, Essilor, _just happens_ to have their expensive proprietary product named specifically as the first intervention.

The "task force on myopia" that published the white paper this press release references is made up almost exclusively of people who had to disclose financial ties to industries that will directly profit from childhood nearsightedness being reclassified from a normal thing that you fix with glasses into a disease with a recommended (and expensive) treatment protocol.

> technically it's the same with proper RPis, where they're the only SBC board (not x86 baed) that you're guaranteed will have at least some software support after 5+ years

This isn't quite true, though it's true at the RPi's price point. For example, Toradex (disclosure: I work for Toradex) produces the colibri-imx6 system-on-module that can be turned into an SBC with a stock carrier board. It was introduced in 2014, continues to be supported today, and will continue to be supported until 2036. But that level of long-term support and maintenance costs money, and the pricing reflects that.

I noted this in reply to the comment above, but: the YAML 1.2 spec doesn't actually mandate that parsers use the Core Schema. They left it as a recommendation. So I don't consider it to be "fixed" at all.

I would not say it "fixed" the problem. It removed the _recommendation_ for parser implementations to use the regex `y|Y|yes|Yes|YES|n|N|no|No|NO|true|True|TRUE|false|False|FALSE|on|On|ON|off|Off|OFF` for parsing scalars as bools, it changed the _canonical_ presentation of bools from `y|n` to `true|false`, and it introduced the "schema" concept. It also introduced and recommended the use of the Core Schema, which uses `true|True|TRUE|false|False|FALSE` as the regex for inferring bools from scalars. But unsurprisingly, since using this schema is only a recommendation and not a requirement, many implementations elected to keep their backwards-compatible implementations that use the original regex.

So the Norway problem persists.

Jesus, this is the absolute antithesis of MINASWAN.

> Ten years ago, GitHub was behind on certain topics (hello CI), but they are now way ahead of the competition.

This is an absolutely wild statement to me. I find github actions to be really terrible for any reasonably complex CI flows; gitlab's CI is the primary reason we use it instead of github. If github's CI was worth a damn we'd certainly be there; as it is we mirror a bunch of repos to github just for discoverability.

My guy, read the blog post before responding. Not only has Stevan written a stateful property-based testing library, the article you didn't read addresses at great length the question of "why".

Yes, but people are allowed to express a strong opinion on a complex subject without also specifically mentioning all the caveats and possible counter-arguments to their position.

By all means argue back and add the nuance you think is missing, but it's intellectually dishonest and lazy to just say "ah, but it's more complicated than that".

One brand new wifi gotcha I just learned about, specific to 5GHz wifi: in the EU, that frequency band is used by other things, including radar for air traffic control and emergency services aircraft. The solution we decided on for that was to mandate that all 5GHz wifi devices stop broadcasting for a period of 1-10 minutes whenever a "privileged user" demands it.

I discovered this only when I moved to a place that has a higher-than-usual incidence of helicopters flying by and my wifi would randomly disconnect. I eventually solved it by finding the channel within the 5GHz frequency band that was least used by privileged users in my area, and now I only have a drop about once a month. But it used to be 3 or 4 times a day.