Error: No such option: --repo-url (Possible options: --repo-branch, --repo-type, --repository-url)
🤦♂️
@nazokiyoubinbou
I agree there's scope for tools that run on your system. That scope can be achieved if you make things optional.
I don't agree there's scope in what a developer is or isn't allowed to develop. You're not anyone's boss.
As for opt out, you forget that distributions have a faaaar larger influence on what happens to be installed on your system by default then whatever the upstream developers decide to put out there.
@waldi @veronica
I agree there's scope for tools that run on your system. That scope can be achieved if you make things optional.
I don't agree there's scope in what a developer is or isn't allowed to develop. You're not anyone's boss.
As for opt out, you forget that distributions have a faaaar larger influence on what happens to be installed on your system by default then whatever the upstream developers decide to put out there.
@waldi @veronica
Finished a second read of @scalzi 's 'the shattering peace', and only now do I realise that the colony actually *isn't* locked away in a separate universe forever...
@nazokiyoubinbou
No.
I don't subscribe to the idea that there is anything 'in' or 'out' of scope for anyone. You want to write something, and people want to use it? Great. Do that. We already have a scarcity of maintainers, let's not make it worse.
As long as the not-init-system parts can be disabled (and they can be), I see no problem with systemd providing a whole bunch of extra tools that work well with the rest of the system.
@waldi @veronica
No.
I don't subscribe to the idea that there is anything 'in' or 'out' of scope for anyone. You want to write something, and people want to use it? Great. Do that. We already have a scarcity of maintainers, let's not make it worse.
As long as the not-init-system parts can be disabled (and they can be), I see no problem with systemd providing a whole bunch of extra tools that work well with the rest of the system.
@waldi @veronica
@nazokiyoubinbou
You can run systemd without systemd-resolved. I have done so ~forever.
The idea is that it makes certain things easier (e.g., having different DNS configs for different network interfaces), but the systemd developers know and understand that it isn't a valid thing everywhere.
@waldi @veronica
You can run systemd without systemd-resolved. I have done so ~forever.
The idea is that it makes certain things easier (e.g., having different DNS configs for different network interfaces), but the systemd developers know and understand that it isn't a valid thing everywhere.
@waldi @veronica
Choose the 'set debconf priority' option
Remember what the priority is set to currently.
Select 'low'. Congratulations, you're now in expert mode
Choose the 'set users and passwords' option.
You will now see a question whether you want to set a root PW. Choose not to.
Finish the 'set users and passwords' menu item
Go back to the 'set debconf priority' option.
Set the priority back to what it was.
You're not in expert mode anymore.
(2/2)
@veronica @Linux
Remember what the priority is set to currently.
Select 'low'. Congratulations, you're now in expert mode
Choose the 'set users and passwords' option.
You will now see a question whether you want to set a root PW. Choose not to.
Finish the 'set users and passwords' menu item
Go back to the 'set debconf priority' option.
Set the priority back to what it was.
You're not in expert mode anymore.
(2/2)
@veronica @Linux
@Linux
Sudo is enabled if you choose not to set the root password. This requires you to go into expert mode in the installer though, although you don't have to do the full install that way.
What I do:
Run the installer normally
When prompted to enter the root PW, use the 'back' button until you're in the main menu
(1/2)
@veronica
Sudo is enabled if you choose not to set the root password. This requires you to go into expert mode in the installer though, although you don't have to do the full install that way.
What I do:
Run the installer normally
When prompted to enter the root PW, use the 'back' button until you're in the main menu
(1/2)
@veronica
@strypey
I agree with the message, but I read "masking" first as the type involving ffp2 etc things and so I was very confused when it started talking about autism 😂
@autistics @ashiel
I agree with the message, but I read "masking" first as the type involving ffp2 etc things and so I was very confused when it started talking about autism 😂
@autistics @ashiel
@mattskala
Oh no. That was discussed in a bug report that this thread links to, but that's a terrible idea.
This is about adding an *option* to ls to swap the symlink and what that points to around in the ls output.
@bkuhn @vagrantc @mjw
Oh no. That was discussed in a bug report that this thread links to, but that's a terrible idea.
This is about adding an *option* to ls to swap the symlink and what that points to around in the ls output.
@bkuhn @vagrantc @mjw
@mattskala
Anyone who tries to parse the ls output for symlink status rather than using https://manpages.debian.org/trixie/coreutils/stat.1.en.html (and doesn't do so in a shell with potential output-changing environment variables cleared) deserves for their scripts to be broken.
ls is an interactive program, its output should not be considered parseable.
@bkuhn @vagrantc @mjw
Anyone who tries to parse the ls output for symlink status rather than using https://manpages.debian.org/trixie/coreutils/stat.1.en.html (and doesn't do so in a shell with potential output-changing environment variables cleared) deserves for their scripts to be broken.
ls is an interactive program, its output should not be considered parseable.
@bkuhn @vagrantc @mjw
@collinfunk
That bug fails to notice that it is using confusing language in the documentation.
ln TARGET LINK_NAME
the target can reasonably be assumed to be the file that is created. But in the case of ln, it's the target *of* the file that is created.
I think that is where my confusion stems from, and I think this language should be updated.
I can't quite think of a good replacement for TARGET, though.
@bkuhn @mjw
That bug fails to notice that it is using confusing language in the documentation.
ln TARGET LINK_NAME
the target can reasonably be assumed to be the file that is created. But in the case of ln, it's the target *of* the file that is created.
I think that is where my confusion stems from, and I think this language should be updated.
I can't quite think of a good replacement for TARGET, though.
@bkuhn @mjw