Debian’s “secret” sauce
lwn.net
lwn.net
Currently, the most accessible big-endian platform that I know of is the Raspberry Pi running NetBSD.
FreeBSD is not Linux (obviously) so this is making a command named something-linux to boot FreeBSD? seems humiliating somehow
bootoctlinux is the command Cavium added to U-boot to boot an ELF kernel. You can alias it as something else if it makes you feel proud.
Big-endian seems to be something of Thomasson[1] these days. I wonder if there is any real use case apart from testing code to see if it still runs on old machines.
Personally, I find big endian a lot more natural when doing hardware development. I understand there are people who think the opposite. As far as performance it is negligible.. network order is Big, PCIe is little so you are usually eating some conversion on either platform.
I also really don't understand why people thought it was such a hard concept as to largely force Linux (PPC, arm, mips) toward little.
Working with arbitrary-precision arithmetic makes you realise how logical little-endian is (and how weird they appear on a big-endian machine.)
- https://developer.ibm.com/articles/l-power-little-endian-faq...
> I also really don't understand why people thought it was such a hard concept as to largely force Linux (PPC, arm, mips) toward little.
My memory is that it's largely Linus having strong opinions.
Ah, yes: "Let's just try to kill big-endian data, it's disgusting and should just die already." https://lore.kernel.org/lkml/CAHk-=wisMFiBHT7dLFOtHqX=fEve3J...
Switching it, is a fair amount of pain, as you can no longer run binaries from stock under your new mipsel FW.
I worked on a Debian-based product which had a three stage Jenkins -> OBS (Debian packaging) -> OBS (images) CI pipeline that required modernization for various reasons. One option I submitted was to create a Jenkins plugin that exposed a Debian source repository as a multibranch pipeline, as a replacement for the second stage.
The idea was to encode both a Debian source package's version and its binary build dependencies into the SCM revision seen by Jenkins. If either changed, Jenkins would've triggered a build automatically and if the binary package built was pushed back onto the source repository, the tree of dependent packages would be iteratively rebuilt.
I made both a plugin prototype and a Jenkins test instance, using Aptly as a repository manager and a dead-simple Jenkinsfile as build instructions. It was quite an elegant setup that allowed one orchestrator to oversee all the stages of building that product, but it wasn't selected at the end due to too much uncertainty when compared to off-the-shelf solutions. Maybe I should write a blog article about it...
You should!
AFAIK testing is worse than both unstable and stable regarding timely security fixes. In unstable you get a timely fix from upstream, in stable you get a fix by the security team.
For anything that is serious enough, you will get a security fix straight away for both unstable and testing (through the testing-security repository).
For things that are not really that important, yes, you will get the fix later.
Edit: The article is about Debian's packaging and distribution process.
Step 2: Don't deviate excessively from this documentation.
Step 3: See steps 1 and 2.
https://www.debian.org/doc/manuals/project-history/manifesto...
Mmhhmm, yes I’m sure you Know Better™ but maybe don’t complain when you do this to yourself, and then it makes your life hard?
Debian Vim has a sane default which means my Debian .vimrc is only two lines, one to import the Debian defaults and another to set my four-tab settings. Debian Apache has the very useful a2{dis,en}{mod,site} utilities and a standard way of configuring sites in /etc/apache2/sites-available which makes scripting Apache configs very easy to do. GNOME is set up out of the box with sane defaults which means everything just works.
This even extends to how different packages work together. For example Debian Smokeping simply adds an Apache site config which I can then a2enconf and I straight away have Smokeping working with minimal fuss.
Going from Debian to Arch et al is a exercise in figuring out why things doesn't work as it should and finding that it's because the upstream code actually has poor defaults and it was Debian all along that applied their own judgements and came up with better defaults.
Debian also has unattended-updates which is a fantastic tool. And that blends in well with their very conservative packaging approach -- I can enable unattended upgrades with the confidence that Debian won't push through a breaking change. I would never use a similar function in other distros -- especially rolling distros.
No hate to Arch, Fedora, et al. I loved learning the in and outs of Linux playing around with Arch -- I think Arch is a fantastic distro for learning the nuts and bolts of Linux. Fedora was an interesting experience, and I decided after a while it wasn't for me. But for my daily driver, I was very, very happy to migrate back to Debian stable. Debian stable is literally a distro that just works.
I very much dislike this tool. It gives itself the privilege to potentially restart any part of your system. I've seen it restart machines on GCP because it installed a new kernel. It might be fine for home desktop use, but turn it off elsewhere.
Characteristically good piece on this by Russ Cox: https://research.swtch.com/openssl
> "The story of Galactica isn't that people make bad decisions under pressure, it's that those mistakes are the exception."
The story of Debian isn't the mistakes, it's how few mistakes there are. It's an entire operating system that's been release consistently for over 30 years and currently in 78 languages. There are around 122k packages in the official software repository, almost all packaged by the Debian project. In terms of number of possible combinations of installed systems, just in software packages, that's something like 21 googolplex. Or around 445x the number of atoms in the observable universe. Never mind the different architectures and all the different hardware variants they could be installed on.
Even if it wasn't given away _for free_, it would be an impressive achievement.
"Yeah, but one time they had a bug!"
Yes. Of course they did.
And regardless of how you feel about the default the way they went about it broke things for users and made more work KeePassXC's maintainers.
You might disagree but given how easily it could've been avoided I think it's pretty wild.
For users using Debian unstable and even there it was apparently fixed/improved after a week. Debian stable users had no "wild ride" and for the future became the choice to select between the full featured keepassxc version and a minimal variant without non-essential network and IPC features.