Scheduled Maintenance: We are aware of an issue with Google, AOL, and Yahoo services as email providers which are blocking new registrations. We are trying to fix the issue and we have several internal and external support tickets in process to resolve the issue. Please see: viewtopic.php?t=158230

 

 

 

Ecce Lennart

Here you can discuss every aspect of Debian. Note: not for support requests!
Message
Author
User avatar
Danielsan
Posts: 659
Joined: 2010-10-10 22:36
Has thanked: 5 times

Re: Ecce Lennart

#136 Post by Danielsan »

I am not against systemd, there a plenty of bad softwares every where even in the Debian repos, I am against the lack of freedom of choice in Debian, for what? For systemd! The worst init system ever written, from the author of some of worst software I consider: avahi and pulse-audio.

Unfortunately if you think also how all the decision was been taken, you can't avoid to smell something burn starting from the wiki:
Why Debian should default to systemd ?
Fedora, OpenSuSE, Arch and Mageia have already made the choice to use systemd, and it is getting excellent upstream support for a growing number of packages.

Architecture

Systemd is well designed. It was conceived from the top, not just to fix bugs, but to be a correct implementation for the base system services.

Systemd makes the boot process much simpler, entirely removing the need to specify dependencies in many cases thanks to D-Bus activation, socket activation, file/inotify activation and udev integration.
Systemd can handle the boot process from head to toe, without needing to use any of the existing shell scripts.
Systemd is straightforward. The command-line interface is probably the best existing for service management. The unit file format (like .desktop or “ini” files) is completely declarative, can be parsed using standard tools, and is a breeze to maintain.
Systemd unit files, unlike SysV scripts, can usually be shipped by upstream, or at least shared with other distributions (already more than 1000 existing unit files in Fedora) without any changes, the Debian specifics being handled by systemd itself.
Systemd is incredibly fast (1 second to boot). It was not designed with speed in mind, but doing things correctly avoids all the delays currently incurred by the boot process.
The transition plan is easy, since existing init scripts are treated as first-class services: scripts can depend (using LSB headers) on units, units can depend on scripts. More than 99% of init scripts can be used without a modification.
Well designed especially when is behavior is, for same admission of his Author, unpredictable.
Contra change to another initsystem

Any change at all involves work, learning something new, and therefore should be a choice; this decision feels somewhat forced upon us by some who insist it is better for us.
If GNOME requires logind which requires systemd, it is unreasonable to impose such a change on the whole distribution, and ought to find an alternative which doesn't.

Unless the new initsystem retains backward compatiblity, and packages continue to provide sysvinit-style initscripts:

Estimates are that up to 1200 Debian packages may be required to adapt to, and continue to support, such a change.
If packages remove their current initscripts, ports like kFreeBSD and Hurd may be unable to use software that was working before this. (Unless the new initsystem can be ported; this is most likely for OpenRC but completely ruled out for systemd).
Much third-party software outside of the Debian archive, or in-house projects within business, may no longer work without taking effort to port them to a new initsystem.
Some maintainers object to maintaining separate initscripts to support alternate systems.
Declerative systems are nice to look at and might cause fewer problems, but if there is a problem, they are almost impossible to debug. Even more so if you only have a non-working system (as the problem would be in the init system).
At least judging from their documentation they all support significant logging.
Even given the disadvantages of editing init scripts (hard to merge with upgrades, ...) and the resulting reluctance of admins to edit them directly, almost every admin has used this ultima ratio at some time, which indicates the missing flexibility to do so might be a problem with other init systems.

Contra systemd, upstart

Not all functionality can be controlled by configuration files and is instead contained in compiled code and if you need to change something it is difficult.
(mainly systemd) Principle of all-mighty solutions is in its nature authoritarian. All-in-one "solutions" are a characteristic of big companies that want to seduce its users into a vicious circle of using their integrated software, while sacrificing other tools that would give them more benefit, thereby realizing abusive psychological advantage above the user.
Init system supported by a big company may have better support but that support is influenced by interests of that company.
They depend on DBus, which means that if DBus is not working system initialization cannot begin.
Key feature of free software is forking, which saves the software from falling into hands of corrupted people. When a project is corrupted, good developers can fork it and make a new project. But if a software is to complex, than forked project is either also complex, and that could demotivate developers to work on such project.
If makers of systemd and upstart really wanted to contribute to F/OSS community, they could just improve sysvinit, init scripts and add additional software that can be used from shell scripts to achieve the same features they provide. Which is basically what openrc did.
Complex software has more bugs. Software requiring a complex SysV init script at the moment (e.g. Squid) may still need a complex Upstart or systemd definition.
Features provided by these init systems are often compensations for lack of features in software that should have those features, and which should not be in init system; e.g. 'start daemons when they are first used' feature compensates lack of support for inetd in server software.
Boot speed may not be important enough to justify a new init system; BIOS POST, option ROMs, EFI boot may take a long time already, and most server systems are rarely restarted anyway.

Contra systemd

Not portable, by design; uses Linux-specific functionality not available on other platforms.
Binds Debian to being a Linux distribution; even some Linux ports may have to be dropped if systemd stops supporting them.
Violates traditional UNIX principles of simplicity and the separation of kernel/initsystem/userland duties such that components are interchangeable.
Begins a precedent for disruptive change, which may happen again if systemd changes its APIs or deprecates some interfaces (has been described as resembling 'vendor lock-in'; really meaning we must continue to keep up with changes mandated by upstream).
logind can no longer be used standalone, as of systemd v205
plans to replace ifupdown scripts too
conflicts with busybox-syslogd
Questions over agenda / conspiracy theories surrounding GNOME, systemd, and Linux, particularly Red Hat's interest in them.
We don't need the stress associated with ever changing to the newest thing and being lead by the nose down another "rabbit hole". Debian should be a rock amidst the sands, not dust blown by the wind.
Attitudes expressed by those pushing systemd:
disinterest in Debian's ports, in "choice" and the ability to "combine everything with everything else":
misunderstanding of the 'modular' concept; having "some 80+ binaries around" is bloat, it is not modular if they depend on using systemd and its interfaces together as a whole

http://bugs.debian.org/684396#10

http://bugs.debian.org/684396#30

https://plus.google.com/115547683951727 ... RmiAQsW9qf
Lennart Poettering: "The only thing we won't take is patches that make systemd portable to the BSDs or Hurd."
Throwing POSIX completely out of the window: where does reinvention end?
"Systemd ships a growing number of useful, unified command-line interfaces for system settings and control (timedatectl, bootctl, hostnamectl, loginctl, machinectl, kernel-install, localectl)."
"unified" is a bad replacement for complying to standards (such as POSIX) and conventions and power must go along with responsibility
Minimum system dependencies for systemd:
acl dbus glib2 hwids kmod libcap libgcrypt pam attr glibc expat libcap openssl pam perl cracklib db libtirpc libgssglue
That is interesting because the "contra" of leaving sysvinit for another init are more of the sum of the "pro" of the three others challengere.
Anyway, this is the funniest part:
Community

Systemd is a lively project with dozens of developers from various companies, including Red Hat, Samsung and Intel. It integrates contributions from even more individual contributors: to this date, 438 authors, with 63 having at least 10 commits. It can also be noted that two of the Debian maintainers have commit permissions.

Other distributions who switched to systemd were also confronted to a lot of controversy before the switch. After it became clear that rivers didn’t turn into blood, the complaints have only been sporadic.
Systemd’s upstream is very accommodating to distributors. They are taking a lot of Debian’s needs into account, even though it has not yet been decided to make it the default.
Systemd developers participate to a lot of conferences, they hold regular hackfests and always ask for feedback on their plans from downstreams (including Debian) before going ahead with them.

Systemd ships high quality documentation, including manual pages for all tools and configuration files, as well as design documents and administration tutorials.
This is the saddest, because this part is magically appeared after the "victory" of systemd, someone wanted to investigate after the forced selection of systemd and he revised a lot of inaccuracies about openrc just to support systemd.
Rebuttals

From the Systemd page: "one of the primary improvement of OpenRC over the sysinit is cgroups" - it's wrong, cgroups are just a minor feature that can extend some use-cases, however pros on this page describes much more features that come with OpenRC (to not duplicate them here). Systemd authors and supporters are trying to let everyone believe that cgroups is the best thing invented since sliced bread, and that it is very complex, which isn't truth.
From the Systemd page: "The primary selling point of OpenRC is that it is portable. Otherwise, it is merely a sysvinit on steroids.". Well, again, that's not truth, OpenRC does a lot more than just this, this shows very little understanding and investigation from the author of these words.
From the Systemd page: "There have been many comments on supposed lack of documentation on systemd’s internals or interfaces. 10% of the source code (14 kLoC) are comments. Each component has its detailed manual page." Then we can read suppositions about the hardness/ease of reimplementing Logind. Well, what has been said by the authors of OpenRC is that re-implementing logind isn't hard, but making a replacement behave exactly like it means that one needs to reverse engineer Logind and read the source code, which shouldn't be the case. This has nothing to do with the (useless) hard dependency on Systemd that has been added on version 205 of Systemd.
From the Systemd page: "Many discussions are centered on systemd-logind as in being the only problem to address by other proposals, wildly proposing seemingly easy-to-develop replacements." Well yes, because it seems that it's being forced to everyone (for example by Gnome), and it imposes systemd starting at version 205. So having a way to replace it is important, otherwise, we are effectively locked-in both systemd and logind. Then on the same page, we can read: "It is hard because without systemd, you are missing the necessary features to implement this service."

The systemd page uses Linux as being monolithic as an argument, which has absolutely nothing to do with the discussion about too many things in the PID1 (it is by the way my opinion that Linux is a way too monolithic though).

From the systemd page: "Many are complaining about the absence of shell scripts, quoting ease of administration or embedded systems. Shell scripts are not easy to maintain or debug; systemd unit files are." Probably. Though Upstart jobs and OpenRC runfiles are equally easy to maintain, and that's not what has been discussed: others wrote that systemd is hard to maintain, and debugging a system which refuses to boot with systemd isn't as easy as it use to be systemd. Anyone who pretends something else is just lying.

Overall, the systemd page is using very aggressive tone like: "boil down to rumors or irrelevant political stances". Saying that your opponent is just "spreading FUD" or that all arguments just "boil down to rumors" isn't helping the debate. Plus highlighting that the systemd author clearly stated that he would refuse any non-linux port is very relevant, and is about a policy from the upstream authors.
From the sysvinit page: "Was only really brought up as a counter-argument for a switch to Systemd, there may not have been such motivation to switch to this from sysvinit otherwise." This is untruth. My interest for OpenRC came after discussing (face to face) with one of the OpenRC upstream maintainers (Patrick Lauer also lives in Shanghai), and after searching for ways to more or less do what OpenRC is capable of (I even went to start writing my own lib, then scrapped that project), with as motivation to offer an interface for simplifying existing init scripts in Debian packages without changing every components of the system.

From the sysvinit page: "No objections seen yet [note: to OpenRC] in discussions, but this init system is the least familiar to us yet". Well, to a degree, this is the init system with which everyone is already familiar with, since it doesn't change any of the interfaces we are already used to: update-rc.d and invoke-rc.d have been re-implemented so that they call rc-update transparently, runscripts live at the exact same place were init scripts use to live and just need to replace them. Read what's below (the example runscript and so on) and you will have to agree! :)
Is that really so funny?
Systemd is a lively project with dozens of developers from various companies, including Red Hat, Samsung and Intel.

User avatar
Danielsan
Posts: 659
Joined: 2010-10-10 22:36
Has thanked: 5 times

Re: Ecce Lennart

#137 Post by Danielsan »

Fortunately RMS had already thought to a solution for our headache: Daemon managing Daemons

User avatar
edbarx
Posts: 5401
Joined: 2007-07-18 06:19
Location: 35° 50 N, 14 º 35 E
Been thanked: 2 times

Re: Ecce Lennart

#138 Post by edbarx »

Systemd is well designed. It was conceived from the top, not just to fix bugs, but to be a correct implementation for the base system services.

Systemd makes the boot process much simpler, entirely removing the need to specify dependencies in many cases thanks to D-Bus activation, socket activation, file/inotify activation and udev integration.
Systemd can handle the boot process from head to toe, without needing to use any of the existing shell scripts.
Systemd is straightforward. The command-line interface is probably the best existing for service management. The unit file format (like .desktop or “ini” files) is completely declarative, can be parsed using standard tools, and is a breeze to maintain.
Systemd unit files, unlike SysV scripts, can usually be shipped by upstream, or at least shared with other distributions (already more than 1000 existing unit files in Fedora) without any changes, the Debian specifics being handled by systemd itself.
Systemd is incredibly fast (1 second to boot). It was not designed with speed in mind, but doing things correctly avoids all the delays currently incurred by the boot process.
The transition plan is easy, since existing init scripts are treated as first-class services: scripts can depend (using LSB headers) on units, units can depend on scripts. More than 99% of init scripts can be used without a modification.
I dare say, the author should seek employment with an advertising company.
Debian == { > 30, 000 packages }; Debian != systemd
The worst infection of all, is a false sense of security!
It is hard to get away from CLI tools.

Randicus
Posts: 2663
Joined: 2011-05-08 09:11

Re: Ecce Lennart

#139 Post by Randicus »

Repeating what has been explained many times. I believe the popular colloquial term is "beating a dead horse." People who do not understand it yet, never will.

For what it is worth, for me the most pertinent part of those quotes is "Questions over agenda / conspiracy theories surrounding GNOME, systemd, and Linux, particularly Red Hat's interest in them." I would not call it a conspiracy, but to me it is clear an important, if not the main, factor behind the decision to adopt systemd is the desire Debian's powers-that-be have to keep Debian a Gnome distribution. Which, of course, raises questions about the project's vision of the future.

User avatar
edbarx
Posts: 5401
Joined: 2007-07-18 06:19
Location: 35° 50 N, 14 º 35 E
Been thanked: 2 times

Re: Ecce Lennart

#140 Post by edbarx »

Until Devuan Stable is released for 64 bit, I am continuing using Debian and Devuan 64 bit as installed through debootstrap and chroot.

One of my coding dreams is to create a custom init from sysvinit's and systemd's code. PID1 would be a simple program that searches for a single configuration file, if it fails to find it, PID1 would provide a working shell. Preferably, the latter is non root. Regarding init scripts, I think, these can be avoided by including only the start and stop commands.

In one of my dangerous experiments, I succeeded to boot a GUI, XFCE4, without an OS initialiser. Obviously, I had to manually start daemons before. I had to use sudo to run XFCE4 as a normal user instead of root.

However, the problem with me is that I have too many interests, most of which are very time consuming. For instance, at the moment, I am literally studying to build an audio amplifier. This means, I am studying how differential pairs work, how audio AB output stages work, and how to improve amplifier linearity. I am trying to keep my differential input pair baised around half the current source's current as at that point differential pairs exhibit linearity.
Debian == { > 30, 000 packages }; Debian != systemd
The worst infection of all, is a false sense of security!
It is hard to get away from CLI tools.

somebodyelse
Posts: 231
Joined: 2015-05-24 17:15

Re: Ecce Lennart

#141 Post by somebodyelse »

mor wrote:And you're right, but what does complaining mean?

I don't think that anybody here is unsympathetic of people saying things like "I'm pissed off that I can't use anything without systemd!" (<- complaining).
It is when people put forward claims such as "there is a violation of software freedoms" (<- incorrect) or "Debian is in cahoots with Redhat and NSA" (<- FUD) and other childish conspiracy theories, that the complaining is no longer a justified and understandable complaint and becomes problematic and bothersome, especially when is brought up in every other thread and often with the not even subtle implication that whoever doesn't believe the conspiracy is real, is either a sheep or a moron or himself in cahoots with Poettering & Co.

It really boils down to that, at least for me.
Yes, this is basically my position. I don't care about systemd. It may well be defective, although Jessie works great for me right now.

It's when you see things that link Debian to the NSA or to Microsoft but when you dig even slightly below the surface of those stories there's nothing. Julian Assange said that all distributions with upstream dependencies (in other words, all distributions) have a risk associated with trusting those upstream sources. He used Debian as one example, presumably because it has traditionally been trusted by revolutionary hacker ninja types. But how many people I wonder have heard "Debian is pwned by the NSA" and taken it as gospel?

But if people want an alternative to systemd, they need to build it. That may sound difficult but isn't the reasoning of the anti-systemd people that they are of sufficient technical competence to see this as a bad thing?

I am uncomfortable about kdbus in the kernel but I trust Linus not to be a ****. The trouble is, Linus trusts Greg KH and I don't, since the only thing I know about him is that he used to work for SUSE, which has a relationship with Microsoft via Attachmate.

millpond
Posts: 698
Joined: 2014-06-25 04:56

Re: Ecce Lennart

#142 Post by millpond »

somebodyelse wrote:The trouble is many things get confused in this debate.

Debian now has systemd as default. So we aren't in the phase of deciding whether we want it. It's there.

Now, is systemd a good thing morally? Don't know but it does satisfy RMS/FSF's/Debian's criteria for free software. Is it a good thing technically? I don't know - both positive and negative arguments are put forward.
Technically RMS/FSF has abandoned us like the Gnostic God, and gone elsewhere.
He has forked Linux -literally.
Including the kernel.
Linus sins.

somebodyelse wrote: Did the technical committee err in selecting systemd? Well they were split 50%/50% so the chair's vote (pro-systemd) carried it. Makes you wonder why have a committee of an even number. Bdale Garbee claims to have done a lot of research into the various proposed alternatives prior to making up his mind. I have no reason not to take him at his word.
But I do.
I totally question the *need* for a new DEFAULT init system.
I do not question the possible utiility of new init systems. And I would certainly be the first to *insist* that systemd be INCLUDED in the Debian Archives, and if it wasnt would add it to my own repos, just like I always add packages that Devian deprecates - I insist on *choice*.

somebodyelse wrote: It strikes me then that for me the choices are:
* Use Debian and use systemd (as it is out of the box now)
* Use Debian without systemd (with a bit of jiggery pokery) AND contribute code or testing support to the packages in Debian that make this possible
* Use Devuan AND contribute to making that work well (again, code and testing)
* Use BSDs/Gentoo/Slackware/Haiku
* Use Windows/OS X
#1 is problematic. I chose Debian and its model, and now it is changing to Redhat. Its of course their *right* , but I would assume they were not acting out of malice, and have not rejected their original 'principles' - and are open to constructive criticism.

#2 Is what I am doing, but need additional information before I start contributing *useful* hacks. This thread has actually added alot of *useeful* unformation and links, particularly
http://www.linuxquestions.org/questions ... 175540922/
which lead me to

#3 This is where some key issues about Devuan were resolved - they apparently DO hack dpkg, and they DO seamlessly integrate the 90+% of the Debian archives that are init agnostic. A crucial issue, and now one that nearly has me itching to add an external repo to my sources.lst.

But not quite, I NEED a *reset* button - or at least a FAQ to restore original Jessie. Or at the very least a HOW-TO on doing a 300Gb ext4 backup *across a network* to to a USB FAT32 drive. If *everything* was confined to /boot /etc and /home /root directories everything would be fine - but /usr is symlinked across 3 drives.


#4 No guarantees they will not get infected. Though arch is an option if things get *really* bad. I can add debian packages there (apparently as source). But it takes a LONG time to compile 20,000 packages.


#5 Sadly I still need Win. Wife needs Office13 for a class, my primary ecommerce database runs only on Win, and if I need to do serious work with USB and optical media Win wins hands down. Miind you, my idea of what Win is probably not yours. I would lay serious odds on that.

somebodyelse wrote: But, Millpond, you are not obligated to use systemd. You have made a conscious decision to use software that has systemd as a dependency. That doesn't affect your freedoms at all. Your freedom is to use an alternative and if no alternative is available to build one.
Well, that is basically what this thread us all about.
How to build a traditional system out of Debian 8.1
Devuan is certainly looking better as a fork of Debian, but I just need the above issues resolved before I make like a frog and jump on what is essentially to me: A production system.
somebodyelse wrote: The point is that no one has let you down. I am not technically qualified to make a technical recommendation to use or not to use systemd. My concern is that there is a lot of badmouthing of the Debian project right now. And that's not acceptable. We'll be sorry when it's gone. And guess who'll be happy?
Dont mistake constructive criticism as badmouthing. Without it we would not even have the shim.
Debian is the one system I have never been able to successfully break.
When I first used it as LMDE/Testing my first reaction was to wipe my other distros.
They served no useful purpose.

I aint giving up on it without a fight.

millpond
Posts: 698
Joined: 2014-06-25 04:56

Re: Ecce Lennart

#143 Post by millpond »

Danielsan wrote:Fortunately RMS had already thought to a solution for our headache: Daemon managing Daemons
Which leads right to
http://www.fsfla.org/ikiwiki/selibre/linux-libre/

The Holy Grail.
But one must be pure of heart.....

User avatar
Sarge-in-charge
Posts: 113
Joined: 2012-07-21 08:41

Re: Ecce Lennart

#144 Post by Sarge-in-charge »

spacex wrote:And that's perfectly fine, but doesn't RedHat have user forums?
I guess so. But then, I am still running on Squeeze.

User avatar
buntunub
Posts: 591
Joined: 2011-02-11 05:23

Re: Ecce Lennart

#145 Post by buntunub »

Randicus wrote:I would not call it a conspiracy, but to me it is clear an important, if not the main, factor behind the decision to adopt systemd is the desire Debian's powers-that-be have to keep Debian a Gnome distribution. Which, of course, raises questions about the project's vision of the future.
I think you know probably better than I that there are reasons for this, none of which have anything to do with conspiracy, and everything to do with practicality and sheer, unfettered laziness. It has everything to do with the DDs and maintainers. There simply is a much larger, more vocal crowd in the Debian Gnome camp. Why the Gnome project went whole hog into systemd is beyond me, but there again you have Devs making the decisions. This is also a contributory factor, because in my extensive experience working with Software Engineers, they should be the absolute last people to decide on things like UI design and application usability/customization. They really should just be taking their marching orders from folks who understand how Humans think and behave long-term. As a result of the status quo, you have modern Gnome 3 and Unity, which are probably OK for mobile platforms, but abysmal for Desktop use. Don't even get me started on the bafoonery of Windows 8 and 10, which are yet another clear example of "Devs gone wild". I guess another way to put it is, why would you trust a software engineer to design a human usable UI when they can't even figure out how to color coordinate their day to day clothing?.. And while they may be in a better position to decide on things like systemd, the same concept applies there as well, because again, Devs tend not to think about the long-term consequences of the decisions they make when it comes to things like this. They usually only consider immediate solutions that best fit their needs, and leave the political and long-term consequences for the rest of us to live with.

spacex
Posts: 637
Joined: 2015-01-17 01:27

Re: Ecce Lennart

#146 Post by spacex »

buntunub wrote:This is also a contributory factor, because in my extensive experience working with Software Engineers, they should be the absolute last people to decide on things like UI design and application usability/customization. They really should just be taking their marching orders from folks who understand how Humans think and behave long-term
And you think that devs would like to spend their free-time taking marching orders? No sane person would ever develop something under terms like that. Not for free. That approach can only work with hired developers. Are you going to pay them?

User avatar
buntunub
Posts: 591
Joined: 2011-02-11 05:23

Re: Ecce Lennart

#147 Post by buntunub »

spacex wrote:
buntunub wrote:This is also a contributory factor, because in my extensive experience working with Software Engineers, they should be the absolute last people to decide on things like UI design and application usability/customization. They really should just be taking their marching orders from folks who understand how Humans think and behave long-term
And you think that devs would like to spend their free-time taking marching orders? No sane person would ever develop something under terms like that. Not for free. That approach can only work with hired developers. Are you going to pay them?
This statement makes me think that you believe this is not happening already?.. It's been going on for many years. Not much software of any kind is currently being developed solely for free, including the many bits and pieces that make up the GNU/Linux world. Sure, I know a lot of developers contribute their time to work on some projects here and there, and there are fewer who devote much more free time to some projects. However, projects like systemd and many, many, many others which now have vast influence in the Linux world were developed by mostly paid programmers with an agenda driven by Corporate interests. So yeah, that's happening, and yeah, programmers are marching to the beat of someone elses drum. This is pretty standard stuff here.

The problem is that on many if not most of these projects that decisions on UI design and usability are left to the developers, who are mostly clueless about how this should be done. I have read here and there that some studies on usability were done by Canonical and possibly Red Hat, but who knows how much of that was implemented, if any, and I think its almost none of it judging by the latest Ubuntu releases.

Anyway, that is just the side point. The real point I was trying to make is that software developers tend to do what they do best, which is write lines of code and cackle in glee when validation tests pass and things actually work. They tend not to think or even care about the larger impact of the end results of their creations on the larger LInuxshpere. Why should they?

spacex
Posts: 637
Joined: 2015-01-17 01:27

Re: Ecce Lennart

#148 Post by spacex »

@buntunub

To some degree you are obviously correct, as far as the big ones are concerned, and no doubt, major changes are driven trough by commercial interests. But the principle remains. Nobody can be forced to develop anything. Obviously, somebody can be "bought", but that's another debate.

But to be honest, I'm closing my eyes and ears to what's happening in linux these days. I prefer pretending it isn't happening.

somebodyelse
Posts: 231
Joined: 2015-05-24 17:15

Re: Ecce Lennart

#149 Post by somebodyelse »

I've reached a point of systemd debate fatigue. I simply don't want to waste any more energy on it.

User avatar
edbarx
Posts: 5401
Joined: 2007-07-18 06:19
Location: 35° 50 N, 14 º 35 E
Been thanked: 2 times

Re: Ecce Lennart

#150 Post by edbarx »

When GRUB2 was released, like many, I was shocked to learn it needed scripts to properly update grub.cfg, and that the latter file, could not be edited by hand. However, till this very day, I am using grub2 the way I deem best fit for my needs: I am still editing grub.cfg and I still refrain from using scripts to add more operating systems. The 'irony' is, grub2 works without problems as I can boot all OSs installed.

I dare say, the same will apply to the infamous OS-initialiser. At the end, if Devuan fails, it will be yet another coding project...

If I write a custom OS-initialiser it will definitely be the minimum for my needs. Furthermore, if overlaying software fails to run because of missing libraries, I will create fakes for those. There are specific development tools to investigate which functions are exported by libraries and which functions are imported by both libraries and executables. For further information see my howtos.
Debian == { > 30, 000 packages }; Debian != systemd
The worst infection of all, is a false sense of security!
It is hard to get away from CLI tools.

User avatar
Sarge-in-charge
Posts: 113
Joined: 2012-07-21 08:41

Re: Ecce Lennart

#151 Post by Sarge-in-charge »

buntunub wrote:As a result of the status quo, you have modern Gnome 3 and Unity, which are probably OK for mobile platforms, but abysmal for Desktop use. Don't even get me started on the bafoonery of Windows 8 and 10, which are yet another clear example of "Devs gone wild".
Gnome 3 and Unity are vomit-inducing contraptions. Windows 8 and 10, the same thing.

This decade is going to be hell for the Desktop. Mobile is king, though.

I just had hoped the server arena was going to go through unscathed, and then systemd and kdbus happened.

The horror, the horror!

spacex
Posts: 637
Joined: 2015-01-17 01:27

Re: Ecce Lennart

#152 Post by spacex »

Sarge-in-charge wrote:
buntunub wrote:As a result of the status quo, you have modern Gnome 3 and Unity, which are probably OK for mobile platforms, but abysmal for Desktop use. Don't even get me started on the bafoonery of Windows 8 and 10, which are yet another clear example of "Devs gone wild".
Gnome 3 and Unity are vomit-inducing contraptions. Windows 8 and 10, the same thing.

This decade is going to be hell for the Desktop. Mobile is king, though.

I just had hoped the server arena was going to go through unscathed, and then systemd and kdbus happened.

The horror, the horror!
Nah, W10 was fine as soon as I got rid of the menu entries for the apps, and added fullversion program for chrome, vlc, gimp and you name it. Works fine for me. The only tiles present, are the tiles that I use. But then again, I'm only using it for gaming, so I had to take advantage of the offer. That way my gaming needs is covered for the next 10 years or so.

somebodyelse
Posts: 231
Joined: 2015-05-24 17:15

Re: Ecce Lennart

#153 Post by somebodyelse »

My gaming needs are covered by icebreaker and 2048-qt :-)

User avatar
Sarge-in-charge
Posts: 113
Joined: 2012-07-21 08:41

Re: Ecce Lennart

#154 Post by Sarge-in-charge »

somebodyelse wrote:My gaming needs are covered by icebreaker and 2048-qt :-)
My gaming need are covered with MAME and DOSbox. But I am old skool.

Randicus
Posts: 2663
Joined: 2011-05-08 09:11

Re: Ecce Lennart

#155 Post by Randicus »

I do not choose my OS based on games. And I definitely would not buy a copy of Windows just to play games. Since OpenBSD is not a gaming system, I make due with the occasional game of tiles, for some reason incorrectly call mahjongg.

Locked