Do they have metrics on how many free tier accounts actually use the CI/CD feature and of those how many exhaust the former 2000 minute quota?
I am asking because my use is definitely in the minority of the user base which is just slapping projects into a managed git repo that is not owned by Microsoft.
This was before github decided to allow private repos for free.
> you gave Amazon a lot more information when you purchased the kindle from them.
Kindles are sold in physical locations – at least in the EU, many Kindle owners got their device from a local electronics shop. You don't necessarily have to order them from Amazon. Then, when you unbox it, there is no requirement to register with Amazon or even connect to the internet at all.
>My main gripe is that the files under /etc/rc.d/ are immutable scripts.
If the files/config (I know the author argues they aren't config files) are truely immutable why would the system upgrade command modify them? and how would it as if they are immutable in the same way that running chattr +i somefile on Linux will make a file immutable even to root then I don't understand how the upgrade command is modifying them.
Systemd-d is growing on me, partly because it is being forced upon us but also because once you get over the initial carpet pull from beneath you, you don't need to be exposed to the extra bullshit it brings.
If you want to experience pain with System-d, install a fresh copy of Ubuntu and try to setup /etc/resolv.conf, for an extra challenge try setup /etc/resolv.conf using unbound as a stub resolver.
I was amazed at how much effort I had to spend fighting the OS to just say "Stop managing this file, do not load this file, I am going to manage it"
I spend most of my time with Linux systems so I admire the simplicity of the System V approach. It is interesting to see other people discuss this from a BSD perspective as I have very little exposure to BSD like systems.
BSD seems great, I love reading the security.html page of the OpenBSD project, it has so many great ideas + implementations.
They are not immutable in the 'chflags uchg,schg ' sense.
Updating these files is not in any way shape or form a hassle anymore if you do not update them. etcupdate has that solved. Even mergemaster has specific options to handle unchanged /etc that only diffs in svn-id tags and similar.
But in my opinion the basic premise of the article is false. mergemaster and etcupdate with their diff and 3-way merge capabilities are there because these files are assumed to have local edits.
The startup procedure, scripts, options are expected to be customized; thus the update procedure has handling to preserve local edits.
At least with Ubuntu server it is pretty easy. The system generated /etc/resolv.conf file even tells you how to disable system control in the comments of the file.
> If the files/config (I know the author argues they aren't config files) are truely immutable why would the system upgrade command modify them?
You are confusing the two different scenarios that you need to distinguish.
The first scenario is when a config file is simply a part of a package, managed by the package manager. In any reasonable package manager, if you ever edited a config file manually under /etc, the package manager will never attempt to update it automatically. For example, apt-get will ask you whether you need to preserve the old file, use the new file, or diff-and-edit it manually. This is the reason why the author suggests to move rc.d from /etc to /libexec, because every time you upgrade your system, the package manager will ask you to diff-and-update some random runscripts that you've never written.
The author's point here is that the rc files do not behave like config files, they are closer to programs or executables, the package manager should be able to update them when a new version in installed without annoying the user, just like any other binaries.
---
The second scenario is when a config file is managed by the init system, a script, or a daemon in the system. For example, /boot/grub.cfg is managed by update-grub & os-prober, and ideally one should never edit the file manually.
In this scenario, it's completely off-topic and irrelevant to the original topic of whether rc.d should be treated as libexec, but here's my opinion anyway...
> I was amazed at how much effort I had to spend fighting the OS to just say "Stop managing this file, do not load this file, I am going to manage it"
Never attempt to fight with the system in a brute force manner - edit this file, later the file is edited back, edit again, edit back, and finally "chattr +i" the file, I never understand this mentality. Using "chattr +i" is almost never the correct solution.
All you need to do is politely tell your intention to the daemon in charge, spending 30 minutes (or each time after a system upgrade) to fight with it, can easily save your 5 minutes to read the documentation.
> for an extra challenge try setup /etc/resolv.conf using unbound as a stub resolver.
If you read the documentation, you'll sometimes find your needs are already supported, and managing it manually is not needed in the first place. For example, NetworkManager already comes with builtin, automatic support of a stub resolver. Not only that, it supports both dnsmasq and unbound, and even has extra logic to help you updating the DNS when you're connected to a VPN. All of these features are here to make one's work easier.
Yet one still chooses to fight with the system in the most brute force way such as "chattr +i", at the very least you can turn it off smoothly and it'll never bother you again.
For example,
$ man NetworkManager.conf
> dns
> Set the DNS processing mode.
> default: NetworkManager will update /etc/resolv.conf to reflect the nameservers provided by currently active connections.
> dnsmasq: NetworkManager will run dnsmasq as a local caching nameserver, using "Conditional Forwarding" if you are connected to a VPN, and then update resolv.conf to point to the local nameserver. It is possible to pass custom options to the dnsmasq instance by adding them to files in the "/etc/NetworkManager/dnsmasq.d/" directory. Note that when multiple upstream servers are available, dnsmasq will initially contact them in parallel and then use the fastest to respond, probing again other servers after some time. This behavior can be modified passing the 'all-servers' or 'strict-order' options to dnsmasq (see the manual page for more details).
> systemd-resolved: NetworkManager will push the DNS configuration to systemd-resolved
> unbound: NetworkManager will talk to unbound and dnssec-triggerd, using "Conditional Forwarding" with DNSSEC support. /etc/resolv.conf will be managed by dnssec-trigger daemon.
> none: NetworkManager will not modify resolv.conf. This implies rc-manager unmanaged.
$ man systemd-networked
> by one of the .network files will be ignored. It is also possible to
> explicitly tell systemd-networkd to ignore a link by using
> Unmanaged=yes option, see systemd.network(5).
I guess one reason that everyone's fighting with the system is not realizing the official way of telling one's intention to the system. Perhaps everyone should learn the way GRUB warns its user.
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub2-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#
Perhaps someone should contribute a patch to NetworkManager to add a similar warning.
# DO NOT EDIT THIS FILE. This file is currently under the management
# of NetworkManager. It's automatically generated according to the
# DNS configuration of the current network connection in NetworkManager.
# Any change to this file will be overwritten.
#
# If you are trying to change your DNS resolver per connection, use "nmtui", "nmcli",
# or alternatively, edit "/etc/NetworkManager/system-connections/".
#
# To stop NetworkManager from managing it altogether, edit
# /etc/NetworkManager.conf, set the following and
# restart NetworkManager, before you edit /etc/resolve.conf.
#
# [main]
# dns=none
#
# If you are trying to set up a stub DNS resolver, it's recommended to
# NetworkManager's builtin support. Set "dns=dnsmasq" or "dns=unbound"
#
# See "man 5 NetworkManager.conf" for more details.
These topics are extremely hard to solve from scratch yet they are distilled pretty well in the above articles and they include a further reading section.
I would implore others to have a gander. I wish the same could be said for their documentation.
The use case is in the title. You can use it as a wireless repeater. A more interesting use case would be ethernet over USB and a wireless AP with another interface for client monitoring via airmon.
I have seen fastmail mentioned many times on this thread. They seem to be incorporated in Austrailia. Given that you clearly care about the use of your personal data; wouldn't moving something so sacred to a company incorporated in a country that actively tries to backdoor encryption/push easier wire tapping make you concerned?
Not OP (but another Fastmail customer) - but there's a difference between caring about the use of your personal data from a eaves-dropping/tapping/threat perspective vs having your personal data used to make you the product. Fastmail is a paid service that provides an excellent service/product where the email you send/receive isn't monetised or incorporated into a revenue/ad machine.
Yeah this is all fine once you have accepted the trade offs and designed your threat model around it. People get extremely zealous around this sort of shit.
One decision for another person does not need to be taken by everyone else just because it makes sense for you.
I, like you am concerned about the use of data but I take a different approach. I don't mind if my data is used for product insight/generation once it is aggregated anonymized data, with the caveat that the website and or service is GDPR compliant.
I give bonus points to any website that lets you nuke your account from the profile page without having to jump through e-mail hoops. I had a recent experience of requesting an account erasure under GDPR via e-mail. I expected the usual "are you sure?", "do you know the implications?", "who are you?" but no they just deleted the account straight away. I only found out it had been done by trying to login to the service again.
I am asking because my use is definitely in the minority of the user base which is just slapping projects into a managed git repo that is not owned by Microsoft.
This was before github decided to allow private repos for free.