> one of the Linux developers reverse engineered the protocol, breaking the licensing terms
Tridge never accepted the license terms of BitKeeper and re-implemented client libraries only by observing black box behaviour of the server, so at no point did he break the terms of the license. He also told Linus what he was doing and asked, "how do you think [Larry McVoy] will react?". Linus said he thought it would be okay.
If you read the bug report there is a period of about 7 weeks where they are asking the maintainer why it was removed, offering to fix it, pointing out that it works fine and can just be put back etc. with no response whatsoever. I don't think there was any further negotiation that could have elicited a response.
The NMU was also delayed by 14 days in order to give the maintainer time to respond. Which they did. Within 3 hours, to simply say "please cancel [this NMU]."
Don't get me wrong: I use systemd and have no interest in going back to sysvinit, but to say the sysvinit users didn't try hard enough to negotiate here seems rather unfair.
I submitted this as being interesting because I feel it is a turning point in Debian's long init wars.
The most recent Debian General Resolution on init support said something like "we chose systemd but compatibility with other inits is important"
It did not clarify whether a package maintainer was allowed to remove working SysV init support and refuse to add it back, and this is now what is happening here, so I think the end result of this will set a precedent within Debian that the vote did not.
The package maintainer has remained quiet on their reasons other than "this is intentional", which again might be interesting because it might speak to whether the maintainer needs to defend their choices at all.
In a hypothetical situation, if an upstream piece of software specifically states that it doesn't support non-systemd systems then I could see how a maintainer might want to remove previously-contributed support for being a burden on future maintenance. I am not saying this is the case here, I am just saying this could be a possible argument for why it's not a black and white matter.
In Debian package maintainers have a lot of leeway on what goes on within their packages. In other Linux distributions there are often more centralised groups who would make such a decision ahead of time as a broad project goal.
In Debian these decisions can get referred to the technical committee but that is often considered "the nuclear option".
So while alternatives could be supported, I guess it's up to the maintainer to decide if these chose to do so. In this case, the maintainer didn't want to, but could of course provide some better argument than "I didn't feel like it and it wasn't a mistake".
When you have a high-level direction set by the organisation, you can't have it arbitrarily overridden by individuals with no discussion and no justification. This permits individuals who act against the overall interests of the organisation in persuit of their own agendas to dictate its path simply by being obstructive or contrary. This is not being a team player, or in fact playing fair at all.
Well, to be fair, the guideline ended up being A) Support systemd and B) Explore alternatives if you want to. In this case, the author chose to do A and not B. That's following the high-level direction and not overriding anything.
I don't believe it is following the high-level direction at all. It's completely counter to it.
Dropping existing working support is deliberately and intentionally stopping alternatives from working. Refusing to consider help from others to maintain this support is deliberately and intentionally preventing alternatives from being supported.
I haven't followed Debian in recent years, but I thought the technical committee had said that maintainers were not to remove working sysvinit support nor refuse patches for it, unless the package itself was clearly tied to the specific init system?
> For the record, the TC expects maintainers to continue to support the multiple available init systems in Debian. That includes merging reasonable contributions, and not reverting existing support without a compelling reason.
Personally I find the /etc/init.d scripts to be crufty & in the way, & would rather not have them in my system.
But I acknowledge there being other folks who for whatever reason prefer SysV style. And the maintainer's silent treatment is pretty harsh.
I would like to give these other users a path forward, but at the same time, I don't want this file in /etc/init.d/ . It's in the way of a better functioning systemd system, I believe; not an area i'm well versed in but I think the init-script helpers expect only an /etc/init.d/ or /etc/systemd/system file, not both, and the /etc/init.d/ script is much less powerful & usable.
Init scripts in /etc/init.d/ are not used when there is a systemd unit of the same name. Other than being in your filesystem they have zero effect on you.
> The most recent Debian General Resolution on init support said something like "we chose systemd but compatibility with other inits is important"
It actually said "Systemd but we support exploring alternatives".
I read this very differently. I read this as Systemd is supported, and if package maintainers wish to include other options they may, with a view to exploring future alternatives.
I don't read this as requiring or prioritising support for previous systems that Debian has moved away from.
What's sad is this is the kind of thing that makes Debian unstable in my eyes. Being able to choose whatever init system you want on your Linux distro is something that should just be a thing.
Additionally I'm confused are these packages not pulled from another source or is Debian the sole developer of this one? I would expect support for other init systems to be in parity with the parent project of the package in question as a result of basing your work off of theirs.
My only experience with Debian packaging is at work and not involved with actual Debian maintainers so I'm unsure of their own process. Is there someone who can shed some light on this?
The init script is specific to Debian. I don't know what network-manager's stance is on init system support or even if they have one. I wasn't able to find one in a quick search.
Oh that's right, it does ask when you upgrade which script you'd like to use.... The package maintainers, yours and possibly the original one(?)... I can't for the life of me remember the options, but I know it usually asks which one you want between yours and the 'package maintainers version' every time you upgrade.
As the article tries to state, the problem isn't that bad blocks can happen. The problems with md's bad blocks log are:
- Most of the time the entries don't correspond to actual bad blocks.
- It's buggy because it copies BBL between devices leading to another instance of "says the blocks are bad but they actually aren't"
- Once you've worked out that the entries are bogus it is still very hard to remove the entries or the BBL as a whole
- It's overly quiet in what it does. I monitor my syslogs but many people don't. There are many documented instances of people carrying entries in a BBL for years without knowing.
- Once MD thinks there is a bad block it renders that block on that device useless for recovery purposes. So in a two device array you just lost redundancy.
So this article has very little to do with the concept of bad blocks; it's about how md's BBL feature can be dangerous and why I don't want it enabled until it's fixed.
To remove the BBL from the devices that make up the array that the root filesystem is on you would need to boot into a rescue environment and assemble it there.
While the debian-installer does provide the rescue environment that you need to do this, it is by no means trivial.
Speaking as the article author I find it way way simpler to create the arrays from the shell at the start, rather than have to remember to reboot into d-i again, choose the rescue mode, tell it not to automatically assemble, drop to shell and assemble there. It's also faster — most of my servers take more than 60 seconds before even the serial-over-lan starts to display output!
By choosing "expert" mode you can choose between any of the partition types (much more besides mbr and gpt). In standard mode it will pick mbr if none of your devices are bigger than the mbr partition limit (2TB?) otherwise it will pick gpt, without offering you a choice.
You can choose expert mode at the start when you boot the installer or you can switch to it from the menu once it's started.
I think you may be right about the other things, but this is not uncommon amongst OS installers. It is very hard to offer the full range of configurations available from all of the tools used to install a Linux system, without just putting the user at a shell prompt and letting them get on with it. Luckily that option is still there!
It's on new devices in an installer context for a RAID-1 as the text you quote describes, so yes I do know what I'm doing. But fair enough, it might give other people bad ideas, so I'll remove it from the examples.
Hi, article author here. That's interesting! I'd possibly never noticed this because my serial console session has always been itself inside screen (now tmux with screen bindings), so doing that would only ever have sent me to my own next window!
I'll have to try it again next time I am in there, with a double escape.
Hi, article author here. I just tried that out on an Ubuntu 18.04 machine but it didn't work:
$ sudo mdadm --fail /dev/md0 /dev/sdb1 --remove /dev/sdb1 --re-add /dev/sdb1 --update=no-bbl
mdadm: set /dev/sdb1 faulty in /dev/md0
mdadm: hot removed /dev/sdb1 from /dev/md0
mdadm: --re-add for /dev/sdb1 to /dev/md0 is not possible
$ sudo mdadm --add /dev/md0 /dev/sdb1 --update=no-bbl
mdadm: --update in Manage mode only allowed with --re-add.
$ sudo mdadm --add /dev/md0 /dev/sdb1
$ sudo mdadm --examine-badblocks /dev/sdb1
Bad-blocks list is empty in /dev/sdb1
Any ideas why? md0 is a simple RAID-1 metadata version 1.2 array.
Interesting. What's the sfdisk for? Is that why my attempts to use --re-add aren't working?
I also tried "mdadm --zero-superblock /dev/sdb1" to make mdadm forget that was ever an array member, but that didn't get me any further.
I use Debian so this won't help me directly, but once I work out why I can't re-add it will be possible to use something similar in a postinst hook to rebuild all the arrays.
The sfdisk is because as part of our kickstart file we only create the first partition. After removing the disk from the raid we repartition it.
I don't see why this couldn't fix up a RAID device generated by the debian installer. The device name could be parameterized if it's not always the same.
We run this script before there's any real data on the device so loss of redundancy for a brief moment is not a huge deal - md0 is a very small device so it doesn't take long to resync.
We repartition it because we're adding partitions.
We have one kickstart file that we use regardless of medium type. For SSDs, we overprovision and leave unused space at the end. Some brands of SSDs were failing before we did that. We don't need to overprovision hard drives.
You could remove the repartitioning and it would do the right thing for your use case.
Ah okay. It seems that my re-adds were failing on arrays that don't have a bitmap. I was testing it on small arrays that don't get a bitmap by default.
Author here. I'm sure you're right. I pretty certain I could have charged them much much more and they'd still have accepted it.
In conversation with the software eng it was implied that they intended to send someone on site to each of over 500 sites to reimage the devices. That must have cost them way more than £70/month and the way that after ~10 months the number of devices actually went up to over 1,000 suggests they were happy to just keep paying.
The thing is, it was essentially no work. All I did was remove a firewall rule. I had to run NTP anyway for my regular customers. Initially more time was spent just in email back and forth and honestly I was enjoying that.
Because of it being basically no work, I had a moral problem with trying to find the absolute highest amount of money they would bear.
I know that is wrong and it does me no good, but I couldn't get past it.
What did annoy me was their inability to pay bills on time, and time I spent chasing invoices and creating custom late payment paperwork that is never relevant for my usual customers.
That was the main impetus for doubling the rate, and despite me jokingly suggesting that their product was not good enough to be profitable (I have no real data on that either way) I suspect they had much bigger organisational problems to be consistently paying late and ending up insolvent.
I like your attitude. If you were stuck fixing the mess the software engineer had to fix, you'd appreciate a random stranger making your life easier when they didn't need to. Maybe they'll pay it forward. Think of the money you didn't charge as your donation to making the world an ever so slightly nicer place!
Tridge never accepted the license terms of BitKeeper and re-implemented client libraries only by observing black box behaviour of the server, so at no point did he break the terms of the license. He also told Linus what he was doing and asked, "how do you think [Larry McVoy] will react?". Linus said he thought it would be okay.
https://lwn.net/Articles/969221/