Devuan: Migrate From Sysv to OpenRC Init - LaskarNix

🙄 Systemd removes legacy support for SysV init scripts

https://github.com/systemd/systemd/releases/tag/v260-rc1

#opensource #systemd #sysv #sysvinit

Release systemd v260~rc1 · systemd/systemd

CHANGES WITH 260 in spe: Feature Removals and Incompatible Changes: * Support for System V service scripts has been removed. Please make sure to update your software *now* to include a na...

GitHub

@sb I remember how it was complicated to create a service using #SysV #initscript and how it's not compatible between distro (initscript template on debian is different with redhat's template).

Love #systemd because systemd unit file resolve that problem for me. Systemd unit file is easier to write and read. And it's universal across distros.

we need T-shirts made:

"I was following online live when they recovered the lost UNIX v4 source (2025 Dec 19)"

#UNIX
#Unixen
#Multics
#SysV

Próxima parada: análisis de puertos, servicios y procesos, nadie quiere que hayan cosas corriendo que puedan ser explotadas por extraños, no? 😉

❓ ¿Les parecen interesantes estos temas? ¿Qué más agregarían? Los leo! 💬

#gnu #linux #systemd #sysV #sysvinit #ciberseguridad #infosec #hardening #curso #juncotic

@[email protected]

#Fossil has way more feature than #git, so much you need a separated forge to fill the gaps a little.

Yet, if you compare fossil and git, the former is way smaller than the latter.

So fossil is both simpler and more featureful, while still looking less "modern" because it clashes with the industrial aestetics of the day.

To me, being able to actually read and modify its source code without being overwhelmed by its complexity turns it to a convivial technology: it's not built to reduce users' and developers' degrees of freedom either through standardization or ui/ux, but to enable them to adapt it to their needs, actually increasing their degree of #freedom.

I think the tension here is rougly the same I see between #C (and #hare) and #Rust, between #Make and #Ninja, between #TinyCC and #LLVM (or #GCC), between #GTK2 and #GTK4, between #SysV and #systemd, between #BSD (or #9front) and #Linux and so on.

Due to the constraints of their age, some older tools are inheritally more suitable to build convivial technologies than other.

Corporations need to alienate their workers, to reduce their degree of freedom, to make them easy to replace. It's not just power play: it's somewhat intrinsic into the need to sell (and thus produce) standardized products that can appeal to many (and thus provide large profits) instead of creating custom solutions for the exact issue at hand that may be orginal, beautiful and tuned to the specific aestetics and goals of a specific (and maybe small) group of people... but need care, access rules and, in general, a community.

Software complexity only really serve industial (maybe militar-industrial) needs.
More often than not, against users.
Always against #developers.

The number of browsers shrinked after #Google launched #Chrome and lured #Mozilla to destroy #Firefox credibility, because a handful of corporations control #WHATWG (and #W3C). #HTML5 requires an overcomplicated #JS engine and #CSS got variables and calc and so on...
And don't even get me start about systemd. Or Linux's 500+ system calls.

C sucks in many ways but there are tons of compilers. Rust looks so "safe" (and is so hyped) that people rewrite working software with it (under permissive licensings that only benefit corporate interests) causing DoS in the wild. And nobody give a shit about the big picture that such incident shows!

But that's the fact with capitalism: it requires deep cultural homologation and submission, so that most people push in the "right" direction by themselves. They may vote differently, dress differently, care about different value but they all need to accept the basic assumptions that enable profit maximization.

Such push to complexity and homologation was lower decades ago because computers were slow and the field was still new.
Thus we got pearls like #forth, #Lisp, #Pascal/#Oberon and so on... even Linux, back in the early 2000 was a convivial technology designed more for people's (developers are still people) needs than for corporate needs.

Now Fossil is in fact modern technology, but it's built on a shitty language (with tons of implementations) that caps its complexity. And I think this is a sort of long term warranty about its usability in convivial contexts.

(sorry for the long reply... grow out of control... I guess this is something I was reasoning about since ages but never had an occasion to formulate...)
Rust Bug Broke Ubuntu 25.10 Automatic Update Checks - OMG! Ubuntu

Ubuntu 25.10's Rust-based coreutils had a bug preventing automatic updates from working. Here's what happened, why it matters, and how it was resolved.

OMG! Ubuntu
Oh. Wait. Just occurred to me: the disk-entries in /dev are block-special files , not directories. Not being directory files, using relative referents (like ../) wouldn't make a lot of semantic sense, I suppose (since one can't cd to a non-directory file-reference). I also suppose it's not solely a #Linux problem, but I don't currently have access to a #BSD or #SysV derived system to compulsively poke at out of curiosity.

In fairness to myself, I don't think I've ever (intentionally)
tried to cd to a file? The only reason I (encountered this) "intentionally" tried to do so, today, is because one of the original authors of the Azure plug-ins for #Packer suggested trying it to work around a limitation in the azure-chroot builder.

Interestingly, while that builder's
mount_partition parameter exists solely to take partition-number as an argument, it's a string data-type rather than an integer data-type. Also, it does no input-validation, so passing it something other than digits/initegers doesn't make it vomit …but passing it a ../mapper/- string sure does (though only because of a "not found" error, not because it doesn't know how to handle the string-value).

It's, uh,
not a well-written plug-in.

#Azure
#IaC
#BuildAutomation

@ytc1 @DenOfEarth @aka_pugs I know.

And espechally in #ScientificComputing a lot of researchers loved working with #SunMicrosystems and when #Oracle took over that relationship got sour'd instantly due to #Oracle #CEO #LarryEllison...

-> https://infosec.space/@kkarhan/114682503920794745

One of the big successes of #Sun was that they basically declared a unilateral "ceasefire" in terms of #IP & #Patents re: #OpenSource. Whereas Oracle didn't seem willing to honour that.

  • Without that cooperative atmosphere we saw #OpenOffice devs literally forking off into @libreoffice and projects like #illumos and @openzfs scramble to save what was OpenSource'd and also rescue that.

Obviously #Linux with it's #GPLv2only-Kernel and most of it's Userland could not get 'closed-sourced' like #OpenSolaris which instantly got stomped out by Oracle as they wanted to sqeeze #Solaris for profits and milk their clients in typical Oracle fashion...

Now granted, I do know someone who for most of their life made their money dealing with the intricacies of setting up #postfix, #sendmail and #courier #MailServers on Solaris and if I ask said person about that they give me a kilometer stare, so OFC like a #SysV - #Unix systems Solaris and #SunOS really are one of the reasons #WindowsNT won the "#WorkstationWar" and why - if anyone - #Apple won the last "#UnixWar"...

  • Still I do am sad that I declined that #sysadmin position at a leading research center I'm not at liberty to name and I do know there's OFC still some critical infrastructure running even older Solaris servers...

https://mastodon.sdf.org/@ytc1/114689337148586939

Kevin Karhan :verified: (@[email protected])

@[email protected] @[email protected] I know. Cade in point, #OpenSolaris did have avid users just below that range, and a lot of #ScientificComputing used it, as they previously used #IRIX. And #Sun being #OpenSourve-friendly was the right direction...

Infosec.Space

Linux Moves to Remove System V File System

Linux developers are planning to remove the aging System V (SysV) file system from the kernel. SysV, once widely used in early Unix systems, is now largely obsolete, with modern alternatives like ext4 and XFS dominating. The removal aims to streamline the kernel and reduce maintenance burden. While some legacy systems may still rely on SysV, its relevance in modern Linux is minimal.

#Linux #SysV #Kernel

SysV filesystem is being removed from Linux 6.15

In the old Unix days, there was a filesystem that implemented the Xenix FS, Coherent Unix FS, and SystemV/386 FS. It allowed file organization and access that provided the data storage service that…

Aptivi