113 karma · joined February 15, 2014
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.
Doesn't putting the exact same partition table on a device that already has a partition table result in no actual changes?
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.
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.
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".
- 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.
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!
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!
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.
I'll have to try it again next time I am in there, with a double escape.
$ 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
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.
It's no secret (although it still surprises some) that only software in the "main" suite is supported by LTS, so all the useful stuff in "universe" for example, may see no updates.
But there are a lot of large pieces of software in main that are already problematic for support across 5 years, let alone 10.
For example what about Django, which is at version 1.11 in Ubuntu 18.04 and uses Python 2. The Django project doesn't intend to release another version that uses Python 2, and Python 2 goes EOL in 2020. So how is Canonical planning to support a complex web framework out to 2028 when the framework is EOL and the scripting language it is based on is also EOL in 2020?
Realistically I think the answer is going to be, "it can't; install it yourself from upstream, or rely on a snap provided by upstream." But that's what the answer always was, and a few answers like that make the promise of 10 year support for main rather hollow.
Is the promise of support just for the kernel and base OS?
The email from Mark seems extremely clear that Canonical's position is that there is no way to distribute a derivative of Ubuntu without 1) joining the Ubuntu community, and 2) asking for permission to distribute.
It does not clarify that all you need to do is remove Canonical's trademarks. It flat out just says that you can't distribute a derivative without permission.
Mark's email is a response to one asking for guidance on what would have to be removed in order to do perform non-infringing distribution. It doesn't ask Ubuntu to do this work of removal. It asks Ubuntu to identify what work needs to be done. mjg59 suggests that he will do the work, possibly by means of having his upload privileges to Ubuntu reinstated. That seems to be an indication of him being willing to do it.
The reply then comes from Mark stating that there is no work that could be done to enable this.
You could certainly create and distribute a tool that would strip trademarks from Ubuntu, and distribute both that tool and your hacked version of Ubuntu, as long as you don't call it Ubuntu.
That appears to be the sort of thing that mjg59 proposed to create, but was told that would never be allowed. Mark's email is literally a response to a request for clarity on what needs to be done to not infringe, i.e. how to do what you are suggesting is permitted.
Mark Shuttleworth has made it clear that in Canonical's opinion there is nothing you can do that would let you skip the step of asking their permission on a case by case basis.
Canonical will not answer a straight-forward question such as "if every instance of every registered Canonical trademark were removed, would that be sufficient?"
This sort of thing has been asked many times.
In fact, going further, Mark Shuttleworth has plainly stated that there is no process or tool which can ever be made that would turn an Ubuntu install into something that could be redistributed, unless permission is first sought on a case by case basis:
https://lists.ubuntu.com/archives/technical-board/2015-Novem...
If Canonical wanted people to be able to redistribute something based on Ubuntu, that does not infringe any Canonical trademark, then it would be very simple for them to enable that. But they don't appear to want to enable that. And without that right, Ubuntu is not free software.
Note that Canonical relies on the right to redistribute a modified version of Debian in order for Ubuntu to exist at all.
http://theshed.hezmatt.org/lvmsync/
except that it works on any block device, not just LVM.
If implementing your own script instead of lvmsync all you need to do is dd off the block device while the VM is running, shut the VM down and then dd only the changed chunks. This can be achieved by reading both the source device and the target device, hashing the chunks and comparing hashes to tell if you need to write the chunk again.
You don't care that the source device is changing under you as you're reading it, because all you're trying to do is get an initial rough copy of the data. The final sync with the VM shut off gets all the changes and makes it consistent.
I typically see single digit changed megabytes per gigabyte of active filesystem, so the final sync goes very quickly.
This also has the advantage that it works in any scenario you have a block device, so would work for OP's host connected to two SANs, but also when you have two hosts each with local storage. You can just do it over SSH.
Another thing you can do is to play with xnbd to put a proxy block device on the destination:
https://bitbucket.org/hirofuchi/xnbd/wiki/Home#!scenario-2-s...
That may be helpful if the storage is local to each host and is truly massive, as a VM on the destination host can use the NBD block device and be unaware that it is proxying requests back to the original host for data it does not have.
Eventually the data will all be synced across to the target host and then the VM can be rebooted to switch back to the non-NBD local block device.
But when systemd is the default init system on almost every Linux distribution, new software will have the systemd integration written first and tested most.
I'm kind of irritated about having to learn a whole set of new things. I do recognise that there are some benefits for my use case in systemd. The desktop stuff aren't the only things that systemd brings.
More than that though, is the fact that it's going to be the new default everywhere. So while you say
I don't particularly like systemd and would be happier not having to deal with the compatibility and/or conversion issues for what I perceive as minimal benefit.
I think you (and I) will actually face more work in trying to avoid systemd than convert to it. You'll be fighting against your distribution's default and the default of every bit of third party software targeted at your distro. From what I have seen most conversions are fairly painless.
So from my position that sits somewhere between "ambivalent" and "that's kind of nice", going with the flow seems the easier path.
Here's a good summary of the issue: http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/de...
A bad thing about systemd and where we are now is the ever-changing API that is mentioned, which hampers alternatives to systemd.
But, that is where we are now, Debian isn't in much of a position to change that, and forking probably isn't going to help with that. Debian wasn't ignorant of that either; these issues were discussed at length in the tech committee debate that originally settled on systemd being the default for jessie.
Absolutely, in that almost anything is. :)
But specifically, at this point I'd really welcome the anti-systemd ranters to just do some work that makes them feel happy, such as making a new distribution that has the exact init system they want.
I suspect that Debian would love for them to do that as well. Debian is in general welcoming of downstream distros since the downstream distros—if given proper care and feeding—often feed back useful improvements to Debian.
The problem here is that no one is actually doing a fork (yet). Some of the same loud, uninformed minority have just created a ranty web page that presents a skewed view of history and makes threats. It's just more of the same interminable mailing list snarks but in web page format.
Trying to put out and support an entire distribution may serve to broaden their minds as to the delicate position the distribution is in with regard to integrating upstream work into a coherent whole.
Sadly I'm not convinced that any enlightenment is going to be achieved because the people behind this web site admit that they haven't even got the time to become involved enough in Debian to have a vote, so I don't know where they're going to find the time to launch a non-toy distribution.
Running systemd as pid 1 does not imply running a desktop environment.
I have plenty of VPS customers running systemd as pid 1 in 512MiB RAM.
Running systemd as pid 1 doesn't imply having every single binary and subsystem of systemd running.
I would encourage you to try it before deciding it's something you won't find useful.
Avoiding it looks like it's going to be significant effort and you'd want to know for sure that you're justified in that before embarking on that course of action.
Their communication throughout the recent suspension of BTC withdrawals hasn't been the best, but I still consider them a pretty good service provider.
The up and coming new exchange Kraken.com looks very impressive. I've only been using it for about a week but their sites seems more professional than average, with two-factor auth, GPG-encrypted emails, and sensible and proportionate account verification steps. They also did not need to suspend their withdrawals which suggests that their wallet implementation is superior to what both MtGox and Bitstamp had prior to this week.
The major downside of Kraken is that their volume is still tiny.
I have also heard reports that they don't give clear indications of which territories they are allowed to trade with, so some people have signed up only to find they are not allowed to actually use the service, because of the country they live in.
I am from UK and have had no such issues. It is a shame that Kraken can't inform people up-front about that though.