You started using it because it had that capability I imagine, not because it is the default. You could easily just alias a command with the right flag if the capability was opt-in.
> You could easily just alias a command with the right flag if the capability was opt-in.
I tried a search to make grep ignore .gitignore because `--exclude=...` got tedious and there was ripgrep to answer my prayers.
Maintaining an alias would be more work than just `rg 'regex' .venv` (which is tab-completed after `.v`) the few times I'm looking for something in there. I like to keep my aliases clean and not have to use rg-all to turn off the setting I turned on. Like in your case, `alias rg='rg -u'`, now how do you turn it off?
> I tried a search to make grep ignore .gitignore because `--exclude=...` got tedious and there was ripgrep to answer my prayers.
To be clear, I was not suggesting an alias for grep, but for a hypothetical alternate ripgrep that searches everything by default but has a flag to skip ignored files. Something like
alias rgi='rg --skip-ignored'
or whatever. Or if it came with a short flag that could work too, so you could use it without an alias easily.
> Like in your case, `alias rg='rg -u'`, now how do you turn it off?
You don't use the same name, you make a new alias. Like rgi or something. Bonus point is you find out immediately if it's missing.
I use very short aliases with fallbacks to standard tools if ripgrep/fd/bat/... isn't installed. For my use searching files in `.gitignore` is useless 9/10 times, why would I want that to be default?
> Or if it came with a short flag that could work too
It does, `-.` for hidden and `-u` for hidden + ignored.
They would have to find someone else if they grew too big.
Though, the secondary doesn't necessarily have to be a maintainer or even a contributor on the project. It just needs to be someone else to do a sanity check, to make sure it is an actual release.
Heck, I would even say that as the project grows in popularity, the amount of people required to approve a release should go up.
So if I'm developing something I want to use and the community finds it useful but I take no contributions and no feature requests I should have to find another person to deal with?
How do I even know who to trust, and what prevents two people from conspiring together with a long con? Sounds great on the surface but I'm not sure you've thought it through.
It wouldn't prevent a project that has a goal of being purposely malicious, just from pushing out releases that aren't actually releases.
As far as who to trust, I could imagine the maintainers of different high-level projects helping each other out in this way.
Though, if you really must allow a single user to publish releases to the masses using existing shared social infrastructure. Then you could mitigate this type of attack by adding in a time delay, with the ability for users to flag. So instead of immediately going live, add in a release date, maybe even force them to mention the release date on an external system as well. The downside with that approach is that it would limit the ability to push out fixes as well.
But I think I am OK with saying if you're a solo developer, you need to bring someone else on board or host your builds yourself.
Why not make it _optional_ but implement on github,etc so any publisher could enable this, no matter how small. But also make it possibel to disable either by support request and small wait or by secondary confirmation or via LONG (months) wait.
Or just don't install every package on the earth. The only supply-chain attack I've been affected by is xz, and I don't think anyone was safe from that one. Your solution wouldn't have caught it.
Better to enforce good security standards than cripple the ecosystem.
I know what an environment variable is, my question is why name them `UV_` instead of `FYN_`? I thought that would've been obvious for exactly the same reason you mention, it should be named for the application they belong to.
I believe Debian doesn't ask for a e-mail address on installation, but the username is obviously necessary if you're going to login. I leave "Users full name" empty and it's fine.
The e-mail address also has a use, for important notifications. There are cases where the OS tries to send an email. But as I mentioned, I don't even know where to set it I've never been prompted and if I was I would leave it empty.
Any app that has access to your age category has access to your home directory where much juicier things live. Probably including your email address, and all your passwords.
I'm a little special and use a hack so I don't even have to provide my e-mail address on git commits to prevent leaking it in my git history. So probably not in my case, but I understand your concern and a lot can be done to improve OS privacy. But "they already know what you eat for breakfast" is not a valid argument to reduce privacy further.
Do you think it's a good idea for operating systems to comply with 1 or 2 exceptionally retarded state laws? The full name is as far as I know never exposed to websites right?
Computers need to stay what they've always been. Chips that we run our programs on. Linux is the last free (as in freedom) option and they will try to take that away too.
No, I don't care about either. It can be argued the full name is technically useful for the system administrators on a multi-user system, but I digress. They can add whatever field they want as long as it's optional.
I do however have a problem with regulating what an OS is required or allowed to do and what it has to collect and expose. Linux wasn't created in the US and there's no reason to comply with the California regulators. Will an empty birthdate field really comply with the law? Is that a fact as you claim?
> Do you not see the discrepancy in your position?
I see you reading more than what I'm actually saying. Breath and re-read what I've said and you will notice that I haven't (until this comment) mentioned my position.
While you're at it maybe answer the questions I asked you instead of replying with more questions, I'll quote them for you:
>> Do you think it's a good idea for operating systems to comply with 1 or 2 exceptionally retarded state laws? The full name is as far as I know never exposed to websites right?
> Do you think it's a good idea for operating systems to comply with 1 or 2 exceptionally retarded state laws? The full name is as far as I know never exposed to websites right?
I think it's a good thing for OS'es to have the capability to comply with laws when it does not impose undue burden on users or developers. This is to avoid there being 40 different forks/patches of a system that would probably be less transparent than having it in the upstream project.
Whether that capability is activated should always be optional. This field is optional.
Regarding this info being exposed to websites is not up to systemd. If for example firefox were to expose this info to websites without my consent I'd support a fork of firefox or stop using firefox.
As long as the info does not leave my computer I feel it is fearmongering to call it mass surveillance.
> Regarding this info being exposed to websites is not up to systemd. If for example firefox were to expose this info to websites without my consent I'd support a fork of firefox or stop using firefox.
> As long as the info does not leave my computer I feel it is fearmongering to call it mass surveillance.
You have to consider the timing and context of the change. What systemd does here is enabling Firefox to share that data (I'm guessing they'll be the last to comply though, Chrome and Safari will jump on it). If you would choose a fork of Firefox over Firefox exposing your data to websites, why are you so eagerly defending systemd exposing the same data to applications?
I tend to apply the same principles to all and react as soon as possible instead of waiting until it's too late. What use is there even of the field if it only stays on your machine, I assume you remember your own birthday?
There are BSDs as well. I wonder how FreeBSD or OpenBSD is going to comply, if at all. There may be a way out of it, too, I am not sure. Perhaps a no-op.
I also wonder how non-systemd Linux is going to handle it. I mean ultimately it may be baked into the kernel in some way or another. It would be pretty sad though.
In any case, I agree. This is just the first step.
I think if there's a law saying, like, GUIs must show stars when you enter your password unless the user clicks the button to make it visible, complying with it is good. Some laws are actually alright.
These all sound like tasks a real sysadmin wouldn't attempt. File browser on a server? Use mv and you can move as many files as you want, sure you'd need a keyboard but I don't see how I would do it with mouse only. Right-click and select multiple? I don't know but it's not a feature I'd even thought of.
Cockpit is great to get a quick glance at the state of servers, but for actual work the terminal is more convenient. Appreciate it for what it is and don't expect a full desktop environment to be included.
It changes permissions nicely and it's nice for my Fedora NAS Jellyfin Torrent server management. It comes preinstalled. Everything that I listed would make the software better.
> The permission model implements a "seat belt" approach, which prevents trusted code from unintentionally changing files or using resources that access has not explicitly been granted to. It does not provide security guarantees in the presence of malicious code. Malicious code can bypass the permission model and execute arbitrary code without the restrictions imposed by the permission model.
Deno's permissions model is actually a very nice feature. But it is not very granular so I think you end up just allowing everything a lot of the time. I also think sandboxing is a responsibility of the OS. And lastly, a lot of use cases do not really benefit from it (e.g. server applications).
It's the reason I started using it. Got sick of grep returning results from node_modules etc.
reply