Assuming the author uses their own software, disabling the ability to hear about problems with it before you trip over it themselves is counterproductive. The minority of users would fix it and offer a PR in my experience, more would be willing to drop the author a note in an issue.
Unfortunately that useful information comes mixed in with, eg, users who think the author's time is worth so much less than theirs (didn't the author demonstrate it was worth nothing by offering this work for free?) they want hand-holding for every little thing. The author can put it in README.md and point these guys at it when closing their issue.
Android is a bit of a siren... since there are many devices on current hardware working great, it looks like it should be possible to be the starting point for a lovely FOSS solution.
But it isn't, due to the Android approach of piling together unmaintainable vendor junk like gpu driver and sensors on old kernel that doesn't work with FOSS gpu apis, radioactive horror story wifi / bt stack using non-upstream apis. The different kernels as a whole are individual flies in amber that are impossible to keep working on newer upstream basis.
Therefore your 'secure FOSS phone' becomes the usual Android security apocalypse as soon as the vendor stops patching the security holes found monthly; that's if your vendor even bothered patching and updating those pieces quarterly or even once.
Purism got it right that there's no way to get the needed result - that it's like putting linux on your x86_64 laptop - out of Android / existing devices. The story seems to be about whether their laptop business and the kickstarter gave them enough runway and ability to pay suppliers up front for initial production.
> But it isn't, due to the Android approach of piling together unmaintainable vendor junk like gpu driver and sensors on old kernel that doesn't work with FOSS gpu apis
That's not the Android approach, it's just the embedded-on-ARM approach that Android inherited wholesale. Pre-Android Linux mobile/embedded OS's were just as bad. In fact, we're starting to see some improvements. The SoC's used in the latest Google Pixel (3 and 4) phones are getting mainline support in the Linux kernel.
The problem isn't that they're somehow oblivious to the various problems... the problem seems to be from this guy's articles that they don't have money and manpower to tackle them.
Yep, the market just can't support this kind of product. So people who know what they're doing won't even touch it and Purism is trying to do their best with totally insufficient resources. And it sounds like their best isn't very good.
Now this whole discussion reminds me of the game Star Citizen. Piles of social money go into it. But in exchange, Star Citizens delivers great demos :-) That's to a point wher I wonder : do people pay for the final product or just ofr the show, the dream it gives them (ie. exactly what you do when you pay for a good movie)...
Their focus has been okay... the foss os stack, the gpu driver the apps... even if they fail other projects can pick these up.
It's just very difficult to get to the point you have enough pieces in good shape for a minimal usable set of functionality in 2019. A month or so ago on a devkit, the browser was crashy and juddery scrolling, not janky but going away to think on things for a bit, failing to update any more etc.
They're kind of responsible for all the pieces in the stack, unlike a normal phone company who get OOT kernel and drivers and gpu pieces handed to them all good by the soc vendor. if they can hold out and keep their nerve, it shows signs it will get there. But maybe in 2-5 years for the software imho.
Fast buses operate at some multiple of a reference clock wired up to both sides, it's often 1/2 or 1/8th of the actual data rate which each side arrives at by feeding the reference clock to an on-die pll.
This can create ambiguity in which bit of the 2 or 8 or whatever is on the bus, and temperature, board design, bus length, humidity etc change the phase where the best sampling place is for the data signal. So there is 'training' to test which fine delay between the receiver pll clock and the data gives the lowest error rate when used to sample the incoming data. Periodically some buses must pause and do retraining to account for, eg, temperature changes.
That email says how the author doesn't like rms or his various writings, then switches to an unrelated drama about how the author fell out with a major contributor and there's some ongoing shitstorm in the project due to that.
The title makes it sound like rms' fault but he only features to be ritually denounced in the first half.
I had to google what guile was I'll certainly be trying to avoid it now.
You appear to have missed where RMS was supposed to have appointed a new co-maintainer without asking anyone in the current team, therefore asserting ownership of a project he was uninvolved with in what appears to a spiteful reason related to his speaking out against RMS. It's in the bottom of the message. It's weird that your response is to threaten to avoid something you've never known about before. Unless you were active in the GNU community already you wouldn't have had reason to use it, so you've not created GNU extensions, were unaware of the language and the threat you're making is that you'll avoid it.
Regardless of whether the statements are accurate, I'll hold judgement until hearing the other side though it does seem odd. I'd be curious what the prospective co-maintainer wants since he quit prior without resolving issues.
Mark's reply should really get a lot more attention.
> Secondly, there was a specific purpose to raising my grievances on the
> internal mailing list. It's because you are vigorously arguing for
> collective decision making within GNU, while at the same time you are
> acting in a dictatorial manner within the Guile project, failing to even
> consult your co-maintainers on core language changes. I think that's
> hypocritical, and I said so.
The email in the original post felt very one-sided and strange. Every single action felt like it was being analyzed to find the worst possible reading. The additional perspective from Mark's reply (especially the above quote) feels more balanced and more rational.
The first half was the setup for the last half, where he talks about how RMS appointed his sort-of-nemesis as co-maintainer without consulting him, which is especially shitty because the author is the actual maintainer of Guile and RMS has nothing to do with it in terms of development, maintenance, or leadership. It's a bizarre and unwise thing to do that threatens the future of the project, and it's all on RMS. So it totally makes sense to me that he spent the first half describing his background with RMS.
There's an appearance of impropriety. Guile's maintainers have been critical of RMS, and now RMS is meddling in the governance of Guile. It seems like the meddling may be to ensure that RMS has allies on that project...
I have a cheap dedicated server with outgoing Postfix mail forwarding with sasl auth, nsd for the domains, a few web services over tls. Git server via gitolite + git-daemon. Mailman.
Incoming mail points directly to an RPi at home on dsl... Postfix + Dovecot IMAP. It's externally accessible, my dedicated server does the dynamic dns to point to the RPi; the domain MX points to that. Outgoing mail forwards through the dedicated server, which has an IP with good reputation and DKIM.
This gets me a nice result that my current and historical email is delivered directly to, and stays at, home, and my outgoing mail is still universally accepted. There's no dependency on google or github. There's no virtualization, no docker, no containers, just Linux on the server and on the rpi to keep up to date. It uses OS packages for everything so it stays up to date with security updates.
> In this study, we estimated a prevalence of EI of ~1/3652 in individuals of European ancestry born in the UK between 1938 and 1967.
This is enough to explain the contents of Arndale Centres, but even adjusted for the reasons they gave to believe it's too conservative, not enough to explain the Daily Express.
Unfortunately that useful information comes mixed in with, eg, users who think the author's time is worth so much less than theirs (didn't the author demonstrate it was worth nothing by offering this work for free?) they want hand-holding for every little thing. The author can put it in README.md and point these guys at it when closing their issue.