Beiträge, die mit Debian getaggt sind
On this episode of This Week in #Linux, we'll talk about some big releases from the #GNOME desktop environment, Sway window manager, distro releases from #Solus, Lakka, #KNOPPIX and #UBports' #Ubuntu Touch. I've got a couple of announcements for this show, #TuxDigital and a Linux Conference I will be attending so be sure to check out that segment. We'll also check out some new releases from #Audacity, #Mesa drivers, NetworkManager, TLP project and more. We'll also look at a new file sharing service provided by #Mozilla. Then we'll discuss some news from the Linux Foundation, #Debian and #HumbleBundle. All that and much more on your Weekly Source for Linux #GNews.
Some very good info material for all now arriving to Linux from the thwart of Spydows 10.
While Ubuntu is based on Debian, there are some areas where the two distros differ. In this video I'll discuss Debian and Ubuntu, how they differ from one another and how despite these differences the two Linux distros manage to do amazing things.
#Linux #MattHartley #Debian #Ubuntu #FreedomPenguin
Si j'en crois ce lien, oui.
Jai acheté un nom de domaine chez #gandi ainsi qu'un serveur cloud #debian 9 chez eux et j'avoue que je suis largué. J'ai suivi des tutos pour préparer le serveur et installer hubzilla et ... je sais pas trop comment relier le serveur cloud au nom de domaine.
J'attends 24-48h un changement de #DNS. Après je donne ma langue au #chat.
Table of contents This post is hard to write, both in the emotional sense but also in the “I would have written a shorter letter, but I didn’t have the time” sense. Hence, please assume the best of…
Article word count: 2250
HN Discussion: https://news.ycombinator.com/item?id=19353010
Posted by secure (karma: 2545)
Post stats: Points: 151 - Comments: 65 - 2019-03-10T17:24:26Z
#HackerNews #debian #down #involvement #winding
Table of contents
This post is hard to write, both in the emotional sense but also in the “I would have written a shorter letter, but I didn’t have the time” sense. Hence, please assume the best of intentions when reading it — it is not my intention to make anyone feel bad about their contributions, but rather to provide some insight into why my frustration level ultimately exceeded the threshold.
Debian has been in my life for well over 10 years at this point.
A few weeks ago, I have visited some old friends at the Zürich Debian meetup after a multi-year period of absence. On my bike ride home, it occurred to me that the topics of our discussions had remarkable overlap with my last visit. We had a discussion about the merits of systemd, which took a detour to respect in open source communities, returned to processes in Debian and eventually culminated in democracies and their theoretical/practical failings. Admittedly, that last one might be a Swiss thing.
I say this not to knock on the Debian meetup, but because it prompted me to reflect on what feelings Debian is invoking lately and whether it’s still a good fit for me.
So I’m finally making a decision that I should have made a long time ago: I am winding down my involvement in Debian to a minimum.
What does this mean?
Over the coming weeks, I will:
* transition packages to be team-maintained where it makes sense * remove myself from the Uploaders field on packages with other maintainers * orphan packages where I am the sole maintainer
I will try to keep up best-effort maintenance of the manpages.debian.org service and the codesearch.debian.net service, but any help would be much appreciated.
For all intents and purposes, please treat me as permanently on vacation. I will try to be around for administrative issues (e.g. permission transfers) and questions addressed directly to me, permitted they are easy enough to answer.
When I joined Debian, I was still studying, i.e. I had luxurious amounts of spare time. Now, over 5 years of full time work later, my day job taught me a lot, both about what works in large software engineering projects and how I personally like my computer systems. I am very conscious of how I spend the little spare time that I have these days.
The following sections each deal with what I consider a major pain point, in no particular order. Some of them influence each other — for example, if changes worked better, we could have a chance at transitioning packages to be more easily machine readable.
Change process in Debian
The last few years, my current team at work conducted various smaller and larger refactorings across the entire code base (touching thousands of projects), so we have learnt a lot of valuable lessons about how to effectively do these changes. It irks me that Debian works almost the opposite way in every regard. I appreciate that every organization is different, but I think a lot of my points do actually apply to Debian.
In Debian, packages are nudged in the right direction by a document called the Debian Policy, or its programmatic embodiment, lintian.
While it is great to have a lint tool (for quick, local/offline feedback), it is even better to not require a lint tool at all. The team conducting the change (e.g. the C++ team introduces a new hardening flag for all packages) should be able to do their work transparent to me.
Instead, currently, all packages become lint-unclean, all maintainers need to read up on what the new thing is, how it might break, whether/how it affects them, manually run some tests, and finally decide to opt in. This causes a lot of overhead and manually executed mechanical changes across packages.
Notably, the cost of each change is distributed onto the package maintainers in the Debian model. At work, we have found that the opposite works better: if the team behind the change is put in power to do the change for as many users as possible, they can be significantly more efficient at it, which reduces the total cost and time a lot. Of course, exceptions (e.g. a large project abusing a language feature) should still be taken care of by the respective owners, but the important bit is that the default should be the other way around.
Debian is lacking tooling for large changes: it is hard to programmatically deal with packages and repositories (see the section below). The closest to “sending out a change for review” is to open a bug report with an attached patch. I thought the workflow for accepting a change from a bug report was too complicated and started mergebot, but only Guido ever signaled interest in the project.
Culturally, reviews and reactions are slow. There are no deadlines. I literally sometimes get emails notifying me that a patch I sent out a few years ago (!!) is now merged. This turns projects from a small number of weeks into many years, which is a huge demotivator for me.
Interestingly enough, you can see artifacts of the slow online activity manifest itself in the offline culture as well: I don’t want to be discussing systemd’s merits 10 years after I first heard about it.
Lastly, changes can easily be slowed down significantly by holdouts who refuse to collaborate. My canonical example for this is rsync, whose maintainer refused my patches to make the package use debhelper purely out of personal preference.
Granting so much personal freedom to individual maintainers prevents us as a project from raising the abstraction level for building Debian packages, which in turn makes tooling harder.
How would things look like in a better world?
1. As a project, we should strive towards more unification. Uniformity still does not rule out experimentation, it just changes the trade-off from easier experimentation and harder automation to harder experimentation and easier automation.
2. Our culture needs to shift from “this package is my domain, how dare you touch it” to a shared sense of ownership, where anyone in the project can easily contribute (reviewed) changes without necessarily even involving individual maintainers.
To learn more about how successful large changes can look like, I recommend my colleague Hyrum Wright’s talk “Large-Scale Changes at Google: Lessons Learned From 5 Yrs of Mass Migrations”.
Fragmented workflow and infrastructure
Debian generally seems to prefer decentralized approaches over centralized ones. For example, individual packages are maintained in separate repositories (as opposed to in one repository), each repository can use any SCM (git and svn are common ones) or no SCM at all, and each repository can be hosted on a different site. Of course, what you do in such a repository also varies subtly from team to team, and even within teams.
In practice, non-standard hosting options are used rarely enough to not justify their cost, but frequently enough to be a huge pain when trying to automate changes to packages. Instead of using GitLab’s API to create a merge request, you have to design an entirely different, more complex system, which deals with intermittently (or permanently!) unreachable repositories and abstracts away differences in patch delivery (bug reports, merge requests, pull requests, email, …).
Wildly diverging workflows is not just a temporary problem either. I participated in long discussions about different git workflows during DebConf 13, and gather that there were similar discussions in the meantime.
Personally, I cannot keep enough details of the different workflows in my head. Every time I touch a package that works differently than mine, it frustrates me immensely to re-learn aspects of my day-to-day.
After noticing workflow fragmentation in the Go packaging team (which I started), I tried fixing this with the workflow changes proposal, but did not succeed in implementing it. The lack of effective automation and slow pace of changes in the surrounding tooling despite my willingness to contribute time and energy killed any motivation I had.
Old infrastructure: package uploads
When you want to make a package available in Debian, you upload GPG-signed files via anonymous FTP. There are several batch jobs (the queue daemon, unchecked, dinstall, possibly others) which run on fixed schedules (e.g. dinstall runs at 01:52 UTC, 07:52 UTC, 13:52 UTC and 19:52 UTC).
Depending on timing, I estimated that you might wait for over 7 hours (!!) before your package is actually installable.
What’s worse for me is that feedback to your upload is asynchronous. I like to do one thing, be done with it, move to the next thing. The current setup requires a many-minute wait and costly task switch for no good technical reason. You might think a few minutes aren’t a big deal, but when all the time I can spend on Debian per day is measured in minutes, this makes a huge difference in perceived productivity and fun.
The last communication I can find about speeding up this process is ganneff’s post from 2008.
How would things look like in a better world?
1. Anonymous FTP would be replaced by a web service which ingests my package and returns an authoritative accept or reject decision in its response.
2. For accepted packages, there would be a status page displaying the build status and when the package will be available via the mirror network.
3. Packages should be available within a few minutes after the build completed.
Old infrastructure: bug tracker
I dread interacting with the Debian bug tracker. debbugs is a piece of software (from 1994) which is only used by Debian and the GNU project these days.
Debbugs processes emails, which is to say it is asynchronous and cumbersome to deal with. Despite running on the fastest machines we have available in Debian (or so I was told when the subject last came up), its web interface loads very slowly.
Notably, the web interface at bugs.debian.org is read-only. Setting up a working email setup for reportbug(1) or manually dealing with attachments is a rather big hurdle.
For reasons I don’t understand, every interaction with debbugs results in many different email threads.
Aside from the technical implementation, I also can never remember the different ways that Debian uses pseudo-packages for bugs and processes. I need them rarely enough to establish a mental model of how they are set up, or working memory of how they are used, but frequently enough to be annoyed by this.
How would things look like in a better world?
1. Debian would switch from a custom bug tracker to a (any) well-established one.
2. Debian would offer automation around processes. It is great to have a paper-trail and artifacts of the process in the form of a bug report, but the primary interface should be more convenient (e.g. a web form).
Old infrastructure: mailing list archives
It baffles me that in 2019, we still don’t have a conveniently browsable threaded archive of mailing list discussions. Email and threading is more widely used in Debian than anywhere else, so this is somewhat ironic. Gmane used to paper over this issue, but Gmane’s availability over the last few years has been spotty, to say the least (it is down as I write this).
I tried to contribute a threaded list archive, but our listmasters didn’t seem to care or want to support the project.
Debian is hard to machine-read
While it is obviously possible to deal with Debian packages programmatically, the experience is far from pleasant. Everything seems slow and cumbersome. I have picked just 3 quick examples to illustrate my point.
debiman needs help from piuparts in analyzing the alternatives mechanism of each package to display the manpages of e.g. psql(1). This is because maintainer scripts modify the alternatives database by calling shell scripts. Without actually installing a package, you cannot know which changes it does to the alternatives database.
pk4 needs to maintain its own cache to look up package metadata based on the package name. Other tools parse the apt database from scratch on every invocation. A proper database format, or at least a binary interchange format, would go a long way.
Debian Code Search wants to ingest new packages as quickly as possible. There used to be a fedmsg instance for Debian, but it no longer seems to exist. It is unclear where to get notifications from for new packages, and where best to fetch those packages.
Complicated build stack
See my “Debian package build tools” post. It really bugs me that the sprawl of tools is not seen as a problem by others.
Developer experience pretty painful
Most of the points discussed so far deal with the experience in developing Debian, but as I recently described in my post “Debugging experience in Debian”, the experience when developing using Debian leaves a lot to be desired, too.
I have more ideas
At this point, the article is getting pretty long, and hopefully you got a rough idea of my motivation.
While I described a number of specific shortcomings above, the final nail in the coffin is actually the lack of a positive outlook. I have more ideas that seem really compelling to me, but, based on how my previous projects have been going, I don’t think I can make any of these ideas happen within the Debian project.
I intend to publish a few more posts about specific ideas for improving operating systems here. Stay tuned.
Lastly, I hope this post inspires someone, ideally a group of people, to improve the developer experience within Debian.
HackerNewsBot debug: Calculated post rank: 122 - Loop: 90 - Rank min: 100 - Author rank: 76
ok so the recommendation lets get done with that. I am an old googleplus user joined while still was not open to public.
#GPlusrefugee #newhere When its about tag newhere I am not really new on the diaspora network as I have accounts from the 2011 and 2012 on some other diaspora nodes. I think first was joindiaspora.com and diasp.org. I am also on friendica currently on the fediverse.me so you can add me as firstname.lastname@example.org or here email@example.com or just search marko.shiva.pavlovic @ other diaspora nodes.
I do not really feel as wanting to follow many people as I hate noise so I will be pretty much selective here you are still open to follow me and I will add my on node address once I set it up.
I am also part of the #KDE project especially #plasmamobile if you want to chat with me can add me on MarkoPavlovic@kdetalk.net
I am part of few other communities too I have many interests some of them you can find in tags on my public profile.
I used to manage and work as owner of #debian #community on the #googleplus which I currently moving to mewe for users who do want to have linux related forum they can join me on fediverse and we can have set up linux and debian related forum for us here.
Anyway I do not like talking a lot about me and prefer talking about ideas.
I was thinking on how to sign this and was thinkin with “have a nice life”. To me personally have a nice life is a word I say in hatred so I will leave this post unsigned. 😀
I personally do not use other networks beside linkedin as I do not love noise and noise is what social networks usually make with all unrelated posts.
Le Collectif Emmabuntüs est heureux d’annoncer la sortie pour le 6 mars 2019, de la nouvelle Emmabuntüs Debian Édition 3 Alpha (32 et 64 bits) basée sur la Debian 10 Alpha 5 Buster et XFCE.
#Debian #GNU #Linux #Emmabuntüs #Réemploi #Solidarité
Converging on Convergence PureOS is Convergent, Welcome to the Future – Purism
Congratulation to #Purism for this great achievement, now we need just the phone!
#freemobile #mobile #android #linux #freesoftware #gnu #debian #convergence #ios #fsf
hi, disclaimer: this has not yet been verified by anyone other than myself, so I could very well be wrong. Reproducible builds are about enabling anyone to independently verify that... ;p ==…
HN Discussion: https://news.ycombinator.com/item?id=19310638
Posted by JNRowe (karma: 149)
Post stats: Points: 136 - Comments: 60 - 2019-03-05T14:19:32Z
#HackerNews #buster #could #debian #only #reproducible #while #will
hi, disclaimer: this has not yet been verified by anyone other than myself,
so I could very well be wrong. Reproducible builds are about enabling
anyone to independently verify that... ;p == Reproducibility in theory == According to https://tests.reproducible-builds.org/debian/buster/index_suite_amd64_stats.html
we have 26476 source packages (92.8%) which can be built reproducibly in
buster/amd64, out of 28523 source packages in total. (These 28523 source packages build 57448 binary packages.) But these tests are done without looking at the actual .deb files distributed
from ftp.debian.org (and we always knew that and pointed it out: "93% reproducible in our current test framework".) == Looking at binary packages Debian actually distributes == So, Vagrant came up with an idea to check buildinfo.debian.net for
.deb files for which 2 or more .buildinfo exist (where "exist" means
that the .deb files sha1sum is listed in the .buildinfo file) and I
turned that into a jenkins job doing this check for all 57448 binary
packages in amd64/buster/main (incl downloading all those .deb files from
ftp.d.o). The current main results (from this job ) are: reproducible packages in buster/amd64: 30885: (53.7600%)
unreproducible packages in buster/amd64: 26543: (46.2000%) and reproducible binNMUs in buster/amd64: 0: (0%)
unreproducible binNMU in buster/amd64: 7423: (12.9200%) == why are binNMUs unreproducible? == Because of their design, binNMUs are unreproducible, see #894441 for
the details (in short: binNMUs are not what they are ment to be: the source
is changed and thrown away) and our proposed solution: ʼbinNMUs should
be replaced by easy "no-change-except-debian/changelog-uploadsʼ. So that accounts for 12%, but 12% are not enough to explain the
difference between 54% and 93%... == packages which have not been rebuilt since December 2016 == And today I remember a thread I started last year in May, titled
"packages which have not been rebuilt since December 2016" (because
these packages were build with an old dpkg not producing .buildinfo
files, which Chris turned into #900837 "release.debian.org: Mass-rebuild of packages for reproducible builds" and so today I ran
Chrisʼ script again on coccia.d.o, and today it showed that ʼonlyʼ
6804 source packages need a rebuild (compared to 9192 eight months ago). 6804 of of 28523 is 23.9%. And 54%+12%+24% equals 90%. Bingo. Bummer. (While #900837 was only filed in 2018 we knew about this issue since
2015 or so... probably earlier. Sigh.) == After the release is before the release. == So, as we first need to fix #894441 before we can sensibly fix #900837 and
because Buster is practically frozen, I think we can just conclude that
Buster is quite reproducible in theory (similar but better than
Stretch...) and that we need to make sure to address #894441 ASAP, which means for Bullseye, the release after Buster. Fur future reference, a summary of the current status of Debianʼs
reproducibiliy is available at
https://wiki.debian.org/ReproducibleBuilds#Big_outstanding_issues Happy hacking and many many thanks to everyone who has contributed so far! https://lists.reproducible-builds.org/pipermail/rb-general/201😲ctober/001239.html
https://wiki.debian.org/ReproducibleBuilds#Big_outstanding_issues -- tschau, Holger ------------------------------------------------------------------------------- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C
Description: PGP signature
HackerNewsBot debug: Calculated post rank: 110 - Loop: 286 - Rank min: 100 - Author rank: 41
The new Mentor Embedded Linux solution is based on Debian, a broadly utilized, enterprise-class, open source Linux OS.
- Mentor Embedded Linux solution is a proven commercial distribution that reduces risk and accelerates productivity for medical, industrial, aerospace and defense applications
- Portability across multiple processor architectures offers increased development flexibility
- Fully-configurable solution for optimal functionality, performance, and productivity
#Siemens #Linux #MentorEmbedded #Debian #Enterprise #LarryToda #embedded #IOT
How can Federation users post more safely?
You know how it goes. We find a great story online and we want to share it with our supporters or feature it in our feed with appropriate hashtags for maximum reach.
But do we check the website featuring the story for privacy before we post?
When we embed a link by selecting the OEmbed box (often ticked by default) this displays an image or video on our post from the website we’ve featured.
They may look cool, but these images can contain beacons or other trackers. Embedded trackers also load into the browsers of any user who scrolls down the public feeds.
Should we ensure the website is safe before linking to it?
Actually some do. Posts that don’t feature a website’s images (with the OEmbed box unchecked as below) can actually protect Federation users from a serious amount of surveillance.
Some thoughtful users actually reproduce the article’s main points in their post, to protect their readers from visiting the site itself. They usually supply a link to the original content if one wants more detail and perhaps is protected with tracker blockers. So how do we know a site we recommend is safe?
Here are some privacy tips:
• Consider checking the page’s security/privacy before linking to it.
Using Tor, or a beefed-up Firefox fork or version (for detecting digital fingerprinting), and/or Disconnect, NoScript or Ublock Origin add-ons to reveal a multitude of trackers.
• There is usually more than one website featuring the same story. Consider picking the website with the least trackers and digital fingerprinting.
• Issue a warning in your post about any of the site’s surveillance methods and privacy issues you’ve detected.
• Embedding a picture/video could also make users vulnerable. Consider unchecking the OEmbed box.
In the next post I’ll give examples of a number of websites with low privacy and excessive trackers, commonly featured in the public feeds.
#secure #internet #windows #apple #revenue #streams #developers #Social #media #data #corporations #tracking #trackers #facebook #social #mass-surveillance #gdpr #google #alphabet #location #user #device #setup #private #secure #internet #chrome #tips #tricks #online #os #mobile #ie #safari #apple #ios #ad #revenue #streams #developers #telemetry #consent #windows10 #windows7 #windows81 #microsoft #linux #debian #ubuntu #mate #gnome #grub #iphone #firefox #advertising #android #chrome #browser #browsers #phone #phones #device #Tor #privacy, #humanrights, #anonymity #internet #security #cookies #surveillance #browser #web #onion #router #torbrowser #bridge #proxy #relay #leaks #fingerprint #activity #activitytrackers #spyware #surveillancecapitalism
Antes de migrar de una a otra, técnicamente… ¿ que diferencia hay entre ambas distribuciones GNU+Linux ( Debian vs Devuan ) ? Principalmente, una : Systemd .
En cada sistema GNU+Linux existe un proceso que el Kernel arranca en primera instancia, antes de todos los demás procesos. Es el proceso padre de todos aquellos procesos que a su vez no ti
Best way to run Wine on 64-bit Debian
I am trying to figure out how running Wine in a very cool way, I mean modern and isolated, there are several way to achieve it but I would like to see your opinion!
#debian #linux #winehq #opensource #containers #docker #systemd #systemadmin #floss #foss #freesoftware #sysadmin
certbot revoke --domain DOMAIN --cert-path /etc/letsencrypt/live/ PATH/ TO/ DOMAIN_SPECIFIC/ cert.pem --reason superseded``--reason cessationofoperation/
--reason unspecified (default)?
certbot delete --cert-name DOMAIN.TLD
(1) https://community.letsencrypt.org/t/staging-endpoint-for-acme-v2/49605 ("Client compatibility")
#linux #debian #Server #LetsEncrypt #Certbot #question #Frage #en #de #observerlanguagespecific