What's with the creepy sexualizing of every woman he encounters?
776 karma · joined March 14, 2014
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.
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.
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.
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.
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.
So the Norway problem persists.
They certainly could have filed a response contesting the TRO. Then their customer could have filed another motion, and eventually (7 days later in this case) the judge would have ruled on the substance of it. Their judgement was that it would be preferable to work with the customer to resolve the technical issues with revocation, and submit a joint request to dismiss the TRO. The stated reasoning behind this was that it would be significantly faster than contesting the TRO. This is true: the certs were revoked and the TRO dropped within 3 days.
I think the communication on that point was severely lacking, as they only clarified it three months later and after significant hectoring in two different bug threads: https://bugzilla.mozilla.org/show_bug.cgi?id=1910805#c43
I also think it's reasonable not to take Digicert's statements at face value, given their history. But I think both of the points you made here are wrong:
> You can stick with your policies and revoke the certificate within 24 hours, instead of delaying revocation until a case is open and a motion for a TRO is filed. Digicert failed to do so.
Let's be clear about the timeline: Digicert notified their customers that the certs would be revoked. In between the time they notified the customer and the time of revocation (less than 24 hours), the customer got the ex parte restraining order. Are you suggesting that issuers should revoke certificates without notifying their users, so that the users don't have time to get an emergency TRO? I believe that would be in violation of the BRs.
> You can stick with your policies and revoke the cert in face of the legal consequences, and deal with them accordingly. Again, Digicert failed to do so.
By "revoke the cert in face of the legal consequences" do you mean "openly defy a valid and legal court order"? Because that would also violate the BRs.
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.
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".
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.
This hasn't been true for quite some time. Docker compose v2, written in Go, was released in 2020; v1 finally officially stopped receiving security updates this summer.
[1] https://daniel.haxx.se/blog/2023/08/26/cve-2020-19909-is-eve... [2] https://www.sqlite.org/cves.html
There are also often practical issues related to security patching embedded devices: for example, a downstream supplier's driver can make it impossible to upgrade a kernel unless/until the supplier provides a fix. Of course, strong regulation here could help to drive bad practices like that out of the industry, but I'm not going to hold my breath on that one. The effect of regulation like this would make it harder for manufacturers who don't have the market power to lean on their suppliers to provide security patches.
Finally, it's important that any regulation that mandates or strongly encourages software updates also mandates that the update system itself be implemented in a secure way. This is my specific area of expertise, and I can tell you that it's very often done very badly. A bad update system is a gigantic, flashing red target for attack. So something like mandating signatures (and sig validation) on software update images would be a good start. Mandating the use of TUF-compliant repositories would be even better.
I'm speaking as one of the authors of the Uptane standard for secure software updates in vehicles, and as a life-long proponent of user freedom and open access to the computers we buy. There are possible solutions here, but they are not easy.
I don't think you're being very reasonable here. A lack of diversity is just a piece of data: it might be complete coincidence, or it might be related to some underlying bias or discrimination. "Calling out" a lack of diversity is just bringing attention to that piece of data. If you want to ignore it, fine. If you want to make a case that the lack of diversity isn't a problem and/or has nothing to do with bias, by all means do so. But you can't just tell people to shut up about inconvenient facts until discrimination is proved in a court of law (or to your own satisfaction, or whatever unstated burden of proof you think is sufficient).
Free speech and dissent is important. You might not like it when people point out obvious and available data like "hey, this group seems to be pretty homogeneous", but that doesn't mean those people should shut up.
Those were the first two I checked and they're massively off, so I'm inclined to think the rest of your argument is also in bad faith or misinformed.
I was really fascinated to learn that most North Americans never even encounter the concept of ordocapitalism/ordoliberalism in their basic economics courses. Somehow, a concept of capitalist economic organization that has been the recipe for success for the creation of most successful economic turnaround in modern times is just...ignored?
Is it just that the password autofill feature uses bitwarden under the hood, but you can't actually use a bitwarden account? If so, that should be mentioned/documented somewhere.