As you probably already know by now, the results of the Debian init system coupling general resolution (GR) look like this:Init system coupling GR: results (arrow from A to B means that voters preferred A to B by that margin)
Some random thoughts about them:
The turnout has been the highest since 2010 DPL elections and the 2nd highest among all GRs (!= DPL elections) ever. The highest among all GRs dates back to 2004 and was about dropping non-free. In absolute terms this vote scores even better: it is the GR with the highest number of voters ever.
Clearly there was a lot of interest within the project about this vote. The results appear to be as representative of the views of project members as we have been able to get in the second half of Debian history.
There is a total ordering of options (which is not always the case with our voting system). Starting with the winning option, each option in the results beats every subsequent option. The winning option ("General resolution is not required") beats the runner-up ("Support for other init systems is recommended, i.e., "you SHOULD NOT require a specific init") by a large margin: 100 votes, ~20.7% of the voters. The winning options wins over further options by increasingly large margins: 173 votes (~35.8%) against "Packages may require specific init systems if maintainers decide" (the MAY option); 176 (~36.4%) against "Packages may not require a specific init system" (the MUST NOT option); 263 (~54.5%) against "Further discussion" (the "let's keep on flaming" option).
While judging from Debian mailing lists and news sites you might have gotten the impression that the project was evenly split on init system matters, at least w.r.t. the matter on the ballot that doesn't seem to be the case.
The winning option is not as crazy as its label might imply (voting to declare that the vote was not required? WTH?). What the winning option actually says is more articulated than that; quoting from the ballot (highlight mine):
Regarding the subject of this ballot, the Project affirms that the procedures for decision making and conflict resolution are working adequately and thus a General Resolution is not required.
With this GR the Debian Project affirms that the procedures we have used to decide the default init system for Jessie and to arbitrate the ensuing conflicts are just fine. People might flame and troll debian-devel as much as they want (actually, I'm pretty sure we would all like them to stop, but that matter wasn't on the ballot so you'll have to take my word for it). People might write blog posts and make headlines corroborating the impression that Debian is still being torn apart by ongoing init system battles. But this vote says instead that the large majority of project members thinks our decision making and conflict-arbitration procedures, which most prominently include the Debian Technical Committee, have served use "adequately" well over the past troubled months.
That of course doesn't mean that everyone in Debian is happy about every single recent decision, otherwise we wouldn't have had this GR in the first place. But it does mean that we consider our procedures good enough to (a) avoid getting in their way with a project-wide vote, and (b) keep on trusting them for the foreseeable future.
[ It is not the main focus of this post, but if you care specifically about the implications of this GR on SystemD adoption in Debian, I recommend reading this excellent GR commentary by Russ Allbery. ]
My take home message is that we are experiencing a huge gap between the public perception of the state of Debian (both from within and from without the project) and the actual beliefs of the silent majority of people that make Debian with their work, day after day.
In part this is old news. The most "senior" members of the project will remember that the topic of "vocal minorities vs silent majority" was a recurrent one in Debian 10+ years ago, when flames were periodically ravaging the project. Since then Debian has grown a lot though, and we are now part of a much larger and varied ecosystem. We are now at a scale at which there are plenty of FOSS "mass-media" covering daily what happens in Debian, inducing feedback loops with our own perception of ourselves which we do not fully grok yet. This is a new factor in the perception gap. This situation is intrinsically bad, nor there is blame to assign here: after all influential bloggers, news sites, etc., just do their job. And their attention also testifies of the huge interest that there is around Debian and our choices.
But we still need to adapt and learn to take perceived hysteria with a pinch (or two) of salt. It might just be time for our decennial check-up. Time to remind ourselves that our ways of doing things might in fact still be much more sane than sometimes we tend to believe.
We went on 10+ years ago, after monumental flames. It looks like we are now ready to move on again, putting The Era of the Great SystemD Histeria™ behind us.
Unless you’ve been living under a firewalled rock, you know that IPv6 is coming. There’s also a good chance that you’ve heard that IPv6 doesn’t have NAT. Or, if you pay close attention to the minutiae of IPv6 development, you’ve heard that IPv6 does have NAT, but you don’t have to (and shouldn’t) use it.
So let’s say we’ll skip NAT for IPv6. Fair enough. However, let’s say you have this use case:
A bunch of containers that need Internet access…
That are running in a VM…
On your laptop…
Behind your home router!
For IPv4, you’d just layer on the NAT, right? While SIP and IPsec might have kittens trying to work through three layers of NAT, for most things it’ll Just Work.
In the Grand Future of IPv6, without NAT, how the hell do you make that happen? The answer is “Prefix Delegation”, which allows routers to “delegate” management of a chunk of address space to downstream routers, and allow those downstream routers to, in turn, delegate pieces of that chunk to downstream routers.
In the case of our not-so-hypothetical containers-in-VM-on-laptop-at-home scenario, it would look like this:
My “border router” (a DNS-323 running Debian) asks my ISP for a delegated prefix, using DHCPv6. The ISP delegates a /561. One /64 out of that is allocated to the network directly attached to the internal interface, and the rest goes into “the pool”, as /60 blocks (so I’ve got 15 of them to delegate, if required).
My laptop gets an address on the LAN between itself and the DNS-323 via stateless auto-addressing (“SLAAC”). It also uses DHCPv6 to request one of the /60 blocks from the DNS-323. The laptop puts one /64 from that block as the address space for the “virtual LAN” (actually a Linux bridge) that connects the laptop to all my VMs, and puts the other 15 /64 blocks into a pool for delegation.
The VM that will be running the set of containers under test gets an address on the “all VMs virtual LAN” via SLAAC, and then requests a delegated /64 to use for the “all containers virtual LAN” (another bridge, this one running on the VM itself) that the containers will each connect to themselves.
Now, almost all of this Just Works. The current releases of ISC DHCP support prefix delegation just fine, and a bit of shell script plumbing between the client and server seals the deal – the client needs to rewrite the server’s config file to tell it the netblock from which it can delegate.
Except for one teensy, tiny problem – routing. When the DHCP server delegates a netblock to a particular machine, the routing table needs to get updated so that packets going to that netblock actually get sent to the machine the netblock was delegated to. Without that, traffic destined for the containers (or the VM) won’t actually make it to its destination, and a one-way Internet connection isn’t a whole lot of use.
I cannot understand why this problem hasn’t been tripped over before. It’s absolutely fundamental to the correct operation of the delegation system. Some people advocate running a dynamic routing protocol, but that’s a sledgehammer to crack a nut if ever I saw one.
Actually, I know this problem has been tripped over before, by OpenWrt. Their solution, however, was to use a PHP script to scan logfiles and add routes. Suffice it to say, that wasn’t an option I was keen on exploring.
Instead, I decided to patch ISC DHCP so that the server can run an external script to add the necessary routes, and perhaps modify firewall rules – and also to reverse the process when the delegation is released (or expired). If anyone else wants to play around with it, I’ve put it up on Github. I don’t make any promises that it’s the right way to do it, necessarily, but it works, and the script I’ve added in contrib/prefix-delegation-routing.rb shows how it can be used to good effect. By the way, if anyone knows how pull requests work over at ISC, drop me a line. From the look of their website, they don’t appear to accept (or at least encourage) external contributions.
So, that’s one small patch for DHCP, one giant leap for my home network.
The standard recommendation is for ISPs to delegate each end-user customer a /48 (giving 65,536 /64 networks); my ISP is being a little conservative in “only” giving me 256 /64s. It works fine for my purposes, but if you’re an ISP getting set for deploying IPv6, make life easy on your customers and give them a /48. ↩
I originally posted this in a thread on debian-private, but on further reflection it seems appropriate for a broader audience. So I'm posting it here, as well as on debian-project.
There is quite a lot of discussion in various places about what the recent GR result means. Some are concluding that systemd won in some way that implies Debian is not going to support other init systems, or at least that support for other init systems is in immediate danger. A lot of that analysis concludes that the pro-systemd "side" in Debian won some sort of conclusive victory.
I have a different perspective.
I think we just had a GR in which the Debian developer community said that we, as a community, would like to work through all of the issues around init systems together, as a community, rather than having any one side of the argument win unambiguously and impose its views on those who disagree.
There were options on the ballot that clearly required loose coupling and that clearly required tight coupling. The top two options did neither of those things. The second-highest option said, effectively, that we should feel free to exercise our technical judgement for our own packages, but should do so with an eye to enabling people to make different choices, and should merge their changes and contributions where possible. The highest option said that we don't even want to say that, and would instead prefer to work this whole thing out through discussion, respect, consensus, and mutual support, without giving *anyone* a clear mandate or project-wide blessing for their approach.
In other words, the way I choose to look at this GR is that the project as a whole just voted to take away the sticks that we were using to beat each other with.
In a way, we just chose thet *hardest* option. We didn't make a simplifying technical decision that provides clear guidance to everyone. Instead, we made a complicating social decision that says that, sorry, there's no short cut to avoid having to talk to each other, respect each other's views, and try to reach workable collaborative compromises. Even though it's really hard, even though everyone is raw and upset, that's what the project as a whole is asking us to do.
Are we up to the challenge?
It's been a while since the last DrupalCamp in Melbourne, so the community came together recently to share what they know. Here's a brief wrap up of the two day event.
It's been more than a month since Drupageddon so I thought I would post an update of my previous post.
Commands that help with auditing:
Showing files that have changed on the live server:git status
Looking for code execution attempts via menu_router:select * from menu_router where access_callback = 'file_put_contents'
Another possible code execution attempt via menu_router:select * from menu_router where access_callback = 'assert';
Showing which files are on the live server and not in version control:diff -r docroot repo | grep 'Only in docroot'
Looking for PHP files in the files directory:find . -path "*php"
Looking for additional roles and users:select * from role select * from users_roles where rid=123
Checking the amount of time between when a user logged into your site and their most recent page visit:select (s.timestamp - u.login) / 60 / 60 / 24 AS days_since_login, u.uid from sessions s inner join users u on s.uid = u.uid;
Commands that can help with recovery:
Apply the patch. Hotfix: (SA-CORE-2014-005)curl https://www.drupal.org/files/issues/SA-CORE-2014-005-D7.patch | patch -p1
End active sessions, i.e log everyone out.TRUNCATE TABLE sessions;
Updating passwords:update users set pass = concat('XYZ', sha(concat(pass, md5(rand()))));
If you need help regarding the recent drupal vulnerability feel free to contact me.
Latest security advisory was today.Tags: Tweet
If Barbie I can be a Computer Engineer taught us anything it taught us that Steven and Brian are nice guys. They just want to help, they know how to fix it, and they are there just when you need them to be. And worst of all they don't mean anything by it.
So what's a nice guy to do? You care, you retweet the awesomest feminist blogs, you were ON it during #gamergate. But on a human interaction level how does it go? Here are some ways that you can level up from just that nice guy that I don't call out on everything, but who secretly makes me sad, to awesome guy that makes my day well ...awesome.Read more
There’s many ways to interpret the last GR. The way I see it is how Joey hoped Debian was: the outcome of the poll shows that we don’t want to do technical decisions by voting. At the beginning of this GR, I was supportive of it, and though it was a good thing to enforce the rule that we care for non-systemd setups. Though I have slowly changed my mind, and I think that this final outcome is awesome. Science (and computer science) has never been about voting, otherwise the earth would be flat, without drifting continents.
So my hope is that the Debian project as a whole, will allow itself to do mistakes, iterative trials, errors, and go back on any technical decision if they don’t make sense anymore. When being asked something, it’s ok to reply: “I don’t know”, and it should be ok for the Debian project to have this alternative as one of the possible answers. I’m convince that refusing to take a drastic choice in this point in time was exactly what we needed to do. And my hope is that Joey comes back after he realizes that we’ve all understood and embarrassed his position that science cannot be governed by polls.
For Stretch, I’m sure there’s going to be a lot of new alternatives. Maybe uselessd, eudev and others. Maybe I’ll have a bit of time to work on OpenRC Debian integration myself (hum… I’m dreaming here…). Maybe something else. Let’s just wait. We have more than 300 bugs to fix before Jessie can be released. Let’s happilly work on that together, and forget about the init systems for a while…
P.S: Just to be on the safe side: the rotten tomatoes image was not about criticizing the persons who started the poll, who I respect a lot, especially Ian, who I am convinced is trying to do his best for Debian (hug).
Hello again, young MacGyver!
In the previous issue you learned how to install Drush, Drupal, and contributed modules. If you missed it, make sure you go back and read Part One from the previous issue.Updates
Now that you've successfully installed Drupal and extended it with some awesome contributed modules, it's time to apply a few updates. With Drush, it is easier by far than any method you might currently be using.
Let's get started: Make sure you are working from the root directory of your website. That would be the directory where you find index.php, and I'm going to assume that location for the remainder of this article.
Issue the following command:drush pm-update
That command will check for new versions of core, themes, and all the contributed modules that are enabled on your site. A list of all available updates will be shown on the screen. Review the list and then press “y” at the prompt if you wish to proceed with the updates.
If you proceed with the updates, Drush will make a backup copy of all the out-of-date packages, download the new ones, and then run database updates, if any are required. It's all very quick and you don't even have to open an FTP client.
Alas, sometimes things go awry; often, very awry. That's why Drush stores a backup copy of the updated packages for you. Should an update fail, it will restore the previous versions and notify you there was a problem. Or, if you need to restore manually, you can find the backups in your user's home directory under “drush-backups”.
Now let's say you only want to update Drupal, but none of the contributed projects. Easy enough: this time only check for Drupal core. Let’s use the shorter version of the command, which I prefer:drush up drupal
The command “up” is short for “pm-update”. As in the first example, Drush will backup the installed version, replace it with the latest, and then run database updates, if any are required. In this case, we specified “drupal”, so Drush will only check for updates for Drupal core.
I'm changing jobs!
From February 2015, I will be joining Red Hat as a Senior Software Engineer. I'll be based in Newcastle and working with the Middleware team. I'm going to be working with virtualisation, containers and Docker in particular. I know a few of the folks in the Newcastle office already, thanks to their relationship with the School of Computing Science, and I'm very excited to work with them, as well as the wider company. It's also going to be great to be contributing to the free software community as part of my day job.
This October marked my tenth year working for Newcastle University. I've had a great time, learned a huge amount, and made some great friends. It's going to be sad to leave, especially the School of Computing Science where I've spent the last four years, but it's the right time to move on, It's an area that I've been personally interested in for a long time and I'm very excited to be trying something new.
DrupalSouth is the biggest Drupal gathering in the Antipodes.
We'll be at the Melbourne Convention and Exhibition Centre over three days in early March 2015. March 5-7 to be exact.
Find out more at the website
The call for sessions is open, and we're trying hard to get the word out wide and far, to whisper in new ears, and encourage people of all sorts to share their ideas for sessions so we can create a truly wonderful, inspiring, engaging and fun program for this conference!
For those who may not know, Drupal is an open source content management system. It's used by people and organisations all around the world, for all sorts of web sites. It's also being used as back end application framework for mobile apps! It's amazing what Drupal can do.
Drupal events are the heart and soul of the community that makes Drupal. Bringing people together drives the project forward, and forges friendships.
But we're also part of the wider web. So we want to hear from all sorts of web specialists, not just Drupalists.
Please, submit a session, or simply help us spread the word. The deadline is looming and won't be extended. Get that proposal in by 30 November 2014. https://melbourne2015.drupal.org.au/program/session-submission
A teacher in New York was teaching her class about bullying and gave them the following exercise to perform. She had the children take a piece of paper and told them to crumple it up, stamp on it and really mess it up but do not rip it. Then she had them unfold the paper, smooth it out and look at how scarred and dirty is was. She then told them to tell it they’re sorry. Now even though they said they were sorry and tried to fix the paper, she pointed out all the scars they left behind. And that those scars will never go away no matter how hard they tried to fix it. That is what happens when a child bullies another child, they may say they’re sorry but the scars are there forever. The looks on the faces of the children in the classroom told her the message hit home.
- Using a GR to force others is the wrong approach of getting compatibility.
- We've offered choice before, and we trust our fellow developers to continue to work towards choice.
- Write patches, not useless GRs. We're coders, not bureocrats.
- We believe we can do this, without making it a formal MUST requirement. Or even a SHOULD requirement. Just do it.
From November 6th through the 9th, members of the Mediacurrent team headed to San Francisco for the Bay Area Drupal Camp. Hundreds of Drupal enthusiasts convened at the Palace of Fine Arts to take part in some fantastic sessions, code sprints, and all the San Francisco has to offer. Mark Casias and Matt Davis weigh in for Part 2 of BADCamp's highlights.
Drupal 7.34 and Drupal 6.34, maintenance releases which contain fixes for security vulnerabilities, are now available for download. See the Drupal 7.34 and Drupal 6.34 release notes for further information.Download Drupal 7.34
Download Drupal 6.34
Upgrading your existing Drupal 7 and 6 sites is strongly recommended. There are no new features or non-security-related bug fixes in these releases. For more information about the Drupal 7.x release series, consult the Drupal 7.0 release announcement. More information on the Drupal 6.x release series can be found in the Drupal 6.0 release announcement.Security information
We have a security announcement mailing list and a history of all security advisories, as well as an RSS feed with the most recent security advisories. We strongly advise Drupal administrators to sign up for the list.
Drupal 7 and 6 include the built-in Update Status module (renamed to Update Manager in Drupal 7), which informs you about important updates to your modules and themes.Bug reports
Drupal 7.34 and 6.34 were released in response to the discovery of security vulnerabilities. Details can be found in the official security advisory:
To fix the security problem, please upgrade to either Drupal 7.34 or Drupal 6.34.Known issues
None.Front page news: Planet DrupalDrupal version: Drupal 6.xDrupal 7.x
cilefen begin to work on the When a content entity type providing module is uninstalled, the entities are not fully deleted, leaving broken references issue. Turned out that a necessary dependent issue is already being worked on so he was able proceed well. I am reasonably confident this issue will get resolved in due time. Sam Hermans have advanced Bulk operations does not respect entity access forward which is great but it still needs some work. Let's note that Sam "only" had a core patch reroll so far and yet he was able to move a critical forward! You could do it as well: I will be waiting for you on IRC in channel #drupal-contribute every Friday noon Pacific (9pm CET).
As product designers and experience strategists, we research how people use systems and design products that tap into users’ natural behaviors. We want people to instinctively know how our product works.
Years of research into the human mind tells us that our brains love patterns, the repeated way in which something happens or is done. Our subconscious mind uses what we’ve learned from patterns – like turning a knob will open a door – to instinctively make decisions about what we do throughout our day. This is why we can walk or breathe without thinking about it – we spend most of our time running on autopilot.
We have an understanding of how people make decisions, but we forget to apply this knowledge when communicating our product vision to stakeholders.There are Drawbacks to Designing in the Abstract
Experience design deliverables, or artifacts, are abstract. We too often produce artifacts, intended to build a shared understanding of a product vision, that are hard to understand. Low-fidelity wireframes and complex flow diagrams require stakeholders to think hard about what we are trying to communicate. They mentally fill in the gaps where we lack details. We consistently break Steve Krug’s number one rule: “Don’t make me think!”
Imagine how these abstract artifacts skew conversations about a product:
We show a stakeholder some wireframes and talk them through the features. Once they see them they begin to imagine the ways features will look and act based on similar products they have used.
While perfectly natural, this behavior is problematic – what we envision may be nothing like products this stakeholder has previously used. These assumptions your stakeholder makes will lead to you and your stakeholders having different expectations during product development.
You need to make artifacts as real as possible in order to elicit the most unbiased, unimpeachable feedback from users during research. You do not need to build a fully functioning product to validate your idea.You do need to eliminate or reduce the guesswork needed to understand how your product will work.Make Your Product Vision Real
Prototyping is a great way to eliminate ambiguity so that you get the best results from user research. A prototype is a preliminary model of a product used to show a concept or validate an idea. A prototype should only contain the minimum amount of content, design and functionality needed to demonstrate how the end-product will function.
Context is key to determining fidelity of a prototype. If you are conducting user testing with a tech-savvy group of stakeholders, clickable wireframes may suffice. If you are introducing a new concept to a set of clients, then you may need a higher-fidelity, interactive web page. Your prototype should only contain the fidelity needed to have a meaningful conversation with your users about your product.Build The Right Prototype For You
There are many different approaches to building prototypes. You can link wireframes together to show user flow with a system like inVision, or build interactive features using an open source CMS like Drupal.
When creating prototypes, make sure to include the following:
The main actions that a user can take and the reactions they will receive from interactive elements.
The key messages you want to communicate to users at different stages of their interaction.
A programmatic way to track user behavior while they use the prototype.
Some of the many benefits of prototyping are:
It produces more accurate results from user testing, allowing you to better determine what works and what doesn’t.
It gives you more opportunity to focus on interaction design by forcing you to have conversations about interactive elements during user research rather than development.
Prototypes bring less-apparent usability issues to light earlier in the development process.
You have a potential starting point to work from when beginning development, minimizing the amount of work that needs to be done in the long run.
John Whalen said “UX does not happen on a screen. It happens here. In the mind.” Keep that in mind (no pun intended) as you seek to build a shared understanding of, and validate, your product ideas. The more real you make the experience of interacting with your product early in the design process, the more accurate a feedback you will get from your users. For more thoughts on prototyping, check out Frederic Mitchell’s “Static Prototyping and Keeping Drupal Simple (KDS)” and “The Devil’s in The Details” by Sharon Smith!
Another PSA: something surprising about XML.
As you might all know, XML must be valid UTF-8 (or UTF-16 (or another encoding supported by the parser, but one which yields valid Unicode codepoints when read and converted)). Some characters, such as the ampersand ‘&’, must be escaped (“&” or “&”, although “&” may also work, depending on the domain) or put into a CDATA section (“<![CDATA[&]]>”).
A bit surprisingly, a literal backspace character (ASCII 08h, Unicode U+0008) is not allowed in the text. I filed a bugreport against libxml2, asking it to please encode these characters.
A bit more research followed. Surprisingly, there are characters that are not valid in XML “documents” in any way, not even as entities or in CDATA sections. (xmlstarlet, by the way, errors out somewhat nicely for an unescaped literal or entity-escaped backspace, but behaves absolutely hilarious for a literal backspace in a CDATA section.) Basically, XML contains a whitelist for the following Unicode codepoints:
Additionally, a certain number of codepoints is discouraged: U+007F‥U+0084 (IMHO wise), U+0086‥U+009F (also wise, but why allow U+0085?), U+FDD0‥U+FDEF (a bit surprisingly, but consistent with disallowing the backspace character), and the last two codepoints of every plane (U+FFFE and U+FFFF were already disallowed, but U-0001FFFE, U-0001FFFF, …, U-0010FFFF weren’t; this is extremely wise).
The suggestion seems to be to just strip these characters silently from the XML “document”.
I’m a bit miffed about this, as I don’t even use XML directly (I’m extending a PHP “webapplication” that is a SOAP client and talks to a Java™ SOAP-WS) and would expect this to preserve my strings, but, oh my. I’ve forwarded the suggestion to just strip them silently to the libxml2 maintainers in the aforementioned bug report, for now, and may even hack that myself (on customer-paid time). More robust than hacking the PHP thingy to strip them first, anyway – I’ve got no control over the XML after all.
Sharing this so that more people know that not all UTF-8 is valid in XML. Maybe it saves someone else some time. (Now wondering whether to address this in my xhtml_escape shell function. Probably should. Meh.)
In the middle of November there was a weekend when it was all about Drupal in Hungary. Cheppers was hosting the Drupal Global Training Day Hungary 2014 and I was one of the core organizers of Drupal Weekend Budapest 2014, so we were concerned by the success of both.
The Drupal FullCalendar module makes it easy to build an interactive calendar using the power of Views. The Drupal FullCalendar module uses the JQuery FullCalendar plugin to make it easy to create an event calendar that allows event dates to be changed by drag and drop.
In this episode you will learn:Tags: DrupalDrupal 7Drupal PlanetUI/Design
Apparently (the actual results have not yet been published by the Secretary), the GR is over, and the worst possible option has won. This is an absolutely ambiguous result, while at the same time sending a clear signal that Debian is not to be trusted wrt. investing anything into it, right now.
Why is this? Simply: “GR not required” means that “whatever people do is probably right”. Besides this, we have one statement from the CTTE (“systemd is default init system for jessie. Period.”) and nothing else. This means that runit, or upstart, or file-rc, or uselessd, can be the default init system for zurg^H^H^H^Hstretch, or even the only one. It also means that the vast majority of Debian Developers are sheeple, neither clearly voting to preserve freedom of choice between init systems for its users, nor clearly voting to unambiguously support systemd and progress over compatibility and choice, nor clearly stating that systemd is important but supporting other init systems is still recommended. (I’ll not go into detail on how the proposer of the apparently winning choice recommends others to ignore ftpmaster constraints and licences, and even suggests to run a GR to soften up the DFSG interpretation.) I’d have voted this as “no, absolutely not” if it was possible to do so more strongly.
Judging from the statistics, the only thing I voted above NOTA/FD is the one least accepted by DDs, although the only other proposal I considered is the first-rated of them: support for other init systems is recommended but not required. What made me vote it below NOTA/FD was: “The Debian Project makes no statement at this time on sysvinit support beyond the jessie release.” This sentence made even this proposal unbearable, unacceptable, for people wanting to invest (time, money, etc.) into Debian.
This opens up a very hard problem: I’m absolutely stunned by this and wondering what to do now. While there is no real alternative to Debian at $dayjob I can always create customised packages in my own APT repository, and – while it was great when those were eventually (3.1.17-1) accepted into Debian, even replacing the previous packages completely – it is simpler and quicker to not do so. While $dayjob benefits from having packages I work on inside Debian itself, even though I cannot always test all scenarios Debian users would need, some work reduction due to… reactions… already led to Debian losing out on Mediawiki for jessie and some additional suffering. With my own package repository, I can – modulo installing/debootstrap – serve my needs for $dayjob much quicker, easily, etc. and only miss out on absolutely delightful user feedback. But then, others could always package software I’m upstream of for Debian. Or, if I do not leave the project, continue doing so via QA uploads.
I’m also disappointed because I have invested quite some effort into trying to make Debian better (my idea to join as DD was “if I’ve got to use it, it better be damn good!”), into packaging software and convincing people at work that developing software as Debian packages instead of (or not) thinking of packaging later was good. I’ve converted our versions of FusionForge and d-push to Debian packages, and it works pretty damn well. Sometimes it needs backports of my own, but that’s the corportate world, and no problem to an experienced DD. (I just feel bad we lost some people, an FTP master along them, before this really gained traction.)
I’d convert to OpenBSD because, despite MirBSD’s history with them, they’re the only technically sound alternative, but apparently tedu (whom I respect technically, and who used to offer good advice to even me when asked, and who I think wouldn’t choose systemd himself) still (allying with the systemd “side” (I’m not against people being able to choose systemd, for the record, I just don’t want to be forced into it myself!)) has some sort of grudge against me. Plus, it’d be hard to get customers to follow. So, no alternative right now. But I’m used to managing my own forks of software; I’m doomed to basically hack and fix anything I use (I recently got someone who owns a licence to an old-enough Visual Studio version to transfer that to me, so I can hack on the Windows Mobile 6 version of Cachebox, to fix bugs in one of the geocaching applications I use. Now I “just” need to learn C# and the .NET Compact Framework. So I’m also used to some amount of pain.)
I’m still unresolved wrt. the attitude I should show the Debian project now. I had decided to just continue to live on, and work on the things I need done, but that was before this GR non-result. I absolutely cannot recommend anyone to “invest” into Debian (without sounding hypocriet), but I cannot recommend anything else either. I cannot justify leaving but don’t know if I want to stay. I think I should sleep over it.
One thing I promised, and thus will do, is to organise a meeting of the Debian/m68k people soonish. But then, major and important and powerful forces inside Debian still insist that Debian-Ports are not part of it… yet, all forks of Debian now suffer from the systemd adoption in it instead of having a freedom-of-choice upstream. I’ve said, and I still feel that systemd adoption should have done in a Debian downstream / (pure?) blend, and maybe (parts of) GNOME removed from Debian itself for it. (Adding cgroups support to the m68k kernel to support systemd was done. I adviced against it, on the grounds of memory and code size. But no downstream can remove it now.)