HN user
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.
Correction, the petition for the TRO was filed ex parte. Digicert did not have any opportunity to respond before it was granted.
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.
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.
There's a very useful framework called greenboot[0] for the latter case.
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.
The article says that you call and then speak to an "agent". I wonder if they mean a human agent, or if it's an AI.
I have a big soft spot in my heart for idealistic crypto stuff like this. Everything the author argues is true...but there's no way in hell commercial email providers would actually publish their private keys. The only way it would be in their interest to make it easy to forge old emails would be if a substantial portion of users demanded it, and that's never going to happen.
docker-compose is slow and not quite parallel (because it's written in Python and uses requests internally).
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.
That's the problem, there isn't a good objective measure. Some type of "reasonableness" standard is usually invoked in situations like this, but that kinda just takes us back to square one: what's currently considered reasonable in the industry is pretty terrible.
This would be an absolutely terrible standard. CVEs really, really suck. See, for example, this CVE for curl[1] that was assigned a 9.8. Or read sqlite's page on CVEs[2]. The sqlite issues alone would make this a non-starter, because you're not gonna convince everyone in every piece of software you use to update their version of sqlite.
[1] https://daniel.haxx.se/blog/2023/08/26/cve-2020-19909-is-eve... [2] https://www.sqlite.org/cves.html
One thing that regulators need to be very careful about is how "security updates" are defined, and exactly what manufacturer obligations for issuing security updates should be. CVEs are a notoriously terrible representation of actual security risks, so a measure like "manufacturer must issue new releases that include any released patches for CVEs with a severity rating greater than 9" would be a clear non-starter.
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.
It's not about security by obscurity. A better analogy would be the fight over "tivoization". In safety-critical and highly-regulated systems like automotive and health care, there's a meaningful regulatory interest in ensuring that the devices as sold and authorized to be on the road (or in patients' hospital rooms) don't get modified in dangerous ways. That means that the software and firmware running on each of the dozens of ECUs in a vehicle is part of the (regulated) functional safety spec of the system. There are real, meaningful technical challenges to overcome if you want to meet both the goal of ensuring that dangerous and malicious software can't run in safety-critical domains, and the goal of allowing users to modify their vehicles as they see fit.
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.
Parent poster is saying that the already-released versions, which were released under an open source license, are still open source.
We're using tapir (https://tapir.softwaremill.com/en/latest/), and are pretty happy with it.
No organisation should be "called out" for a lack of - insert-race-here- representation unless that organisation is in fact discriminatory.
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.
That's silly. If we followed your logic, there is no such thing as "at most once" delivery. It's actually "exactly-once" delivery, since if it is 0 it is not a delivery.
What was being asked is whether you're aware that the correct term is "walled garden" (and saying "wallet-garden" as a play on words), or if "wallet-garden" is a mondegreen[1] for you (also recently referred to as a "bone apple tea" thanks to the popularity of a certain subreddit[2]).
Your numbers are massively wrong at a glance, when I went to check them. Microsoft's total number of employees increased by roughly 40k between June 30 2021 and June 30 2022, but a large portion of that increase was from M&A, not from hiring, and they started large layoffs in July 2022. Net hires are not public info, but it's probably more like 15k in the period specified. Amazon has 300k employees total, and they obviously didn't hire all 300k in 2022.
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.
This is one of those worldviews that seems to be common among US-Americans, but sounds totally bizarre from an outside perspective. You say "If you don't want to live in that world, start your own startup, hire people, and never fire them.", but why should that be my course of action instead of working collectively to make sure that companies' decisions are driven by all stakeholders--owners (shareholders), employees, customers, and regulators to the extent that the company's actions generate negative externalities. Why should that be my course of action instead of advocating for change, and expressing my displeasure and outrage when large companies act in ways that I would never accept from a human being with empathy? Yes it's my business, because I live in the world, in a society, and everyone who lives in a society is affected by everyone else.
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?
This looks great! But I'm having a bit of trouble figuring out the bitwarden integration: I already have a bitwarden account (in fact, I run my own self-hosted server), and I can't figure out how to use it in this browser.
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.
This doesn't really make sense. Akka is a framework/library, not something that could be offered as a service, anymore than you could have "boost as a service" or "numpy as a service".
I think that makes this change worse, though: it means that the new license will infect many more projects--like Spark, for example. And they won't even be making security patches to existing versions available under the old license. "Nice project you got there, it'd sure be a shame if some unpatched security flaw came along and ruined it," they're saying.
edit: I wasn't aware, but Spark stopped using akka several years ago. But the basic point still stands.
The reversion to Apache is part of the BSL license, including the specific timeline of the reversion. So although they could decide later on to change the license again (for example, making it completely proprietary), all of the code released under the BSL will eventually become open source.
If I contributed to the project, I did so under the premise of the LICENSE that was active when I contributed. If I didn't like OSS, I wouldn't have contributed to a OSS project. Them changing the license is a middle-finger to me as a contributor.
No, you contributed under the premise of the LICENSE that was active when you contributed _and the CLA they made you sign before they accepted your PR_, which said that they're allowed to change the license later on if they feel like it. If you think that the company changing the license for future versions is a middle finger, you shouldn't be contributing to projects that make you sign CLAs.
I'm a bit skeptical of your claim that "getting a work permit in Europe basically isn't possible without a degree".
Is it an EU country? In every European country I've had direct experience with (DK, DE, IT, PT, FR, BE), you can get a residence permit with the right to work by applying as an accompanying spouse, or under a family reunification scheme. Of course, in some countries this can take time, but certainly not 8 years.
Additionally, under the 'Directive on the status of non-EU nationals who are long-term residents'[1], you have the right to obtain permanent residence in any EU country you have lived in legally for 5 years. Unless you've been living in the EU illegally (e.g. on a tourist visa for 8 years) or not reporting your income/paying social contributions, you should be eligible for that. As with all/most EU directives, the specific implementation can vary between countries, but the immigration authorities are obliged to have some kind of process for implementation.
[1] https://home-affairs.ec.europa.eu/policies/migration-and-asy...
I'm curious to dig into this a bit more. In general, I'm skeptical about those use cases.
* If it's a governance token system where more money == more power...well, I just don't think it's a good idea in general.
* If it's a system that tries to replicate the idea of one person/one vote, you have to have KYC (and re-KYC upon membership transfer) or it devolves into the first case. Then the entity doing KYC has centralized control over membership, so it seems like storing membership info on a ledger doesn't offer any benefits compared to just having a central membership database.
That's a bit misleading--you can only stake for 10% if you agree to lock up a large amount of money in CRO for a long period of time, and if you agree to a three month fixed-term deposit for the USDC you're "staking". CRO exposes you to arguably more risk than the staking is worth, and the fixed-term deposits have the downside risk of crypto.com literally collapsing and not being able to pay you back.
If you want staking rewards on USDC (from crypto.com) without a fixed-term deposit, the best you can do is 2%. If you want to avoid having to lock up $40,000 in CRO for a minimum of 6 months, the best you can do is 1.5%. Given that you can earn 0.7% on a FDIC-insured deposit in actual USD, that's not much of a deal.