It definitely feels like there's a dedicated core of people insisting on removing choice from the Linux ecosystem. RedHat, Gnome, fredesktop.org ... they have an ideology and a strategy to make it dominant in the Linux world and it does not feel nice to many people.
This article is using "fake" for click-bait purposes, implying some kind of scam, in fact it's just a filler RGB stick to make pretty lights inside your case, nothing nefarious about it and it's clear when you buy, but probably wouldn't be featured on HN without it.
"I'd like 32G but I can't afford 2x16G right now so I'll buy a single stick and keep a slot open for later when prices are better or I get more available money". Seems pretty easy to understand.
I'm amazed by the lengths Americans will go to try to convince themselves they're the good guys. America never has and never will go to war to liberate a people from oppression and spread democracy or other fairy tale. America goes to war for one thing and that is defend the interests of America and its proxy in the middle East, Israel.
So the interests of the US are the continuation of its imperialist control over the world through oil and the dollar, and those of Israel the expansion of its hegemonic domination over the middle East.
However this time, while Israel does indeed extend its hegemonic ambitions over the region by invading and bombing Lebanon, the US seem not to be in total control of what's happening in oil markets, the strait of Hormuz, and the toppling of the Iranian regime. There are many factors why, among which the fact that the regime has prepared for years for such a scenario and can not easily be killed by decapitation, and that it actually has partisans and the Iranian people is not going to simply revolt as one.
This war is also a highly assymetrical one, and that's why the comparison with Vietnam is valid.
Interestingly the original author ported the code from the Mozilla C++ version which is licensed as "MPL 1.1 or LGPL" (it's a bit unclear as the readme says that but the license file mentions only MPL). So the author did already relicence the project in a way by licensing the port as LGPL only.
That's a non sequitur. Creating long-term professional politicians is not going to create legislators competent in the various domains they legislate on. It's going to create politicians competent at being elected long term, whatever the means.
Yeah we need not look further than the 70 year old men in the United States senate/congress who have been in their seats for longer than I've been alive, making laws on technology they don't understand.
I don't know what the solution is for California, but I don't think it's that.
The solution is to get money out out of politics. Term limits are good for the exact reason you mentioned. For tech law, there should be some sort of tech committee that knows laws like this are idiotic.
California has term limits (up to 12 years regardless of being in the assembly or senate) and this law still was passed so I don't think you are really selling term limits...
Term limits do prevent situations like the supreme court, where any institutional knowledge and length of terms can be weaponized for political gain.
Overall, if the objective was to have a non-identifying age flag in operating systems, this isn't the end of the world (though I would have preferred enabling other things I've mentioned here in the past like opening up OSes). If there were younger people in the legislature that tried to understand this better than octogenarians, I think term limits are working fine.
Hopefully parents can use the parental control tools built around this non-identifying flag for some good.
The RFC wording is a little weird. If the zone has DNSSEC configured, then the wording should be stronger and use MUST wording, and not imply that CAs will be compliant if they choose to avoid verifying signatures despite the presence of signstures. Likewise, these TXT records for dns-persist-01 ideally "SHOULD NOT" be deployed when DNSSEC is not configured.
An open PR on the draft (#35) adds exactly this language: if a CA performs DNSSEC validation and it fails (expired signatures, broken chain of trust), the CA MUST treat it as a challenge failure and MUST NOT use the record. The rationale is that dns-persist-01 records are long-lived, so a DNSSEC failure has more severe consequences than it would for a transient challenge.
I guess what they're saying is that, for example, a password of length 12 has about 71 bits of entropy if using an alphabet of 62 characters, and 76 bits with an alphabet of 82 characters. But if you only increase the length by 1 you already get 77 bits with 62 characters only. So length beats adding special chars in that sense.
Gotcha, I guess my question is, why not both? Is it the requirement of special chars over a min-length password that is in question here? Like the system is like "minimum 8 char password but also three special chars, ancient heiroglyphs, and the blood of your firstborn child" when you can omit the special chars and just have min 16 char password for the same security benefit?
> I was tempted to try it until I saw the curl | bash pipe, then no
I don't quite get that argument. It's the same as the old download installer from random website, double click to run that people have been doing for decades. It only skips the download step. And it's arguably better since at least you can review the contents. When building a Go program it will also happily download stuff from github but I've seen way less complaints about that. And to be fair it's also been an infection vector, from people installing things from shady places (or reputable places but with ill-intent like installing unwanted browser toolbars, DRM rootkits ...), but it's nothing new. Same advice applies, know what you're doing, use reputable sources.
I don't think the go module system is great but I am not sure if any programming gets it right and all suffer from many issues, but go has the go.mod and it is easy to see what dependencies are being used both direct and indirect and the user can filter and look though these packages and pin them until they have eyeballed updates to the git repo. I don't feel the most comfortable with it but the whole `curl | sh` is so terrible, no signing no, way of knowing about the integrity of the installer.
> What's a better alternative ?
I do not think the program really needs and installer but if one must then why not just have it under source control that way you get the benefits of git handling all the download bits and the install script being completely offline and just using cp or install commands.
you could tell the user to do this with a pithy command like `git --depth=1 clone $GITSITE/$REPO && $REPO/installer.sh && rm -R $REPO`
My big problem with it is uninstallation. If I ever want to remove the program, I have to 1. Hope that the author published an uninstall.sh, or 2. examine the install.sh to see where it spams all its files to and remove them manually. This seems like a major step backwards from package managers.
This is the only reasonable argument I've heard, but in reality I don't find uninstallers do their job anyway, i seldom have an uninstaller that doesn't leave empty folders behind, config files, user files...
You're blind-trusting someone to run stuff in the context of your terminal. Sure, it's similar to an installer but the author of the script can also manipulate the script at any time.
One day you run it, it's fine. The next day you run the same command on your machine, it installs malware. No way to tell without inspecting the script every time.
If you download an installer and it's fine, then you can run it again and it's still fine.
reply