Slashdot Mirror

1) What's wrong calling a helper script a script that help you to do something in a more simple way? Now if it's not from you the script came from something else. In the context of this discussion this is from the distribution.

2) It's not the central part of system V init. The most obvious prof of this is that each distribution family have a different set of helpers scripts. Just take a look at the reality:
https://packages.debian.org/je...
https://packages.debian.org/je...
https://packages.debian.org/je...
If you list the source patch archive http://http.debian.net/debian/... you will see that ALL the initscripts are Debian specific and not part of the original sysvinit http://http.debian.net/debian/... .
Configuring the network is not the same in Fedora an in Debian. On of the long term goal of systemd is to normalize the situation.

3) The problem is to configure an interface automatically when the system boot. In most distribution the users don't even have to use the real command to setup the interface to do this. And you are completely wrong about your ifconfig and script theory: the vast majority of network interfaces are today setup by a dhcp client, or an application like NetworkManager according to DBUS messages coming for example from a GUI application, all written in C or C++, or maybe something other, but for certain shell scripts play a marginal role here. The shell is NOT the primary interface for the vast majority of the users, sysadmin is not the dominant specie in the Linux world.

4) Systemd is really simpler to learn that shell script. I switched some months ago to systemd and found all the documentation is needed in the usual man pages. I took me less than 1 hour to learn the basic commands and I was able to convert the custom part of the system less than one day.

5) You can laugh as you want, this will not change the reality:
* Sysadmins are a minority of Linux users.
* Distributions like Debian support /etc/network/interfaces with systemd.
* There are sysadmin already using systemd.
* To date there is no enough maintainers against systemd to have successfully make an serious alternative available and ready to use by the distribution.
* Systemd transition is now done by Fedora, Ubuntu and Debian and there are still there.
* Still, a lot of forum get post from 'sysadmin' complaining.

1) What's wrong calling a helper script a script that help you to do something in a more simple way? Now if it's not from you the script came from something else. In the context of this discussion this is from the distribution.

2) It's not the central part of system V init. The most obvious prof of this is that each distribution family have a different set of helpers scripts. Just take a look at the reality:
https://packages.debian.org/je...
https://packages.debian.org/je...
https://packages.debian.org/je...
If you list the source patch archive http://http.debian.net/debian/... you will see that ALL the initscripts are Debian specific and not part of the original sysvinit http://http.debian.net/debian/... .
Configuring the network is not the same in Fedora an in Debian. On of the long term goal of systemd is to normalize the situation.

3) The problem is to configure an interface automatically when the system boot. In most distribution the users don't even have to use the real command to setup the interface to do this. And you are completely wrong about your ifconfig and script theory: the vast majority of network interfaces are today setup by a dhcp client, or an application like NetworkManager according to DBUS messages coming for example from a GUI application, all written in C or C++, or maybe something other, but for certain shell scripts play a marginal role here. The shell is NOT the primary interface for the vast majority of the users, sysadmin is not the dominant specie in the Linux world.

4) Systemd is really simpler to learn that shell script. I switched some months ago to systemd and found all the documentation is needed in the usual man pages. I took me less than 1 hour to learn the basic commands and I was able to convert the custom part of the system less than one day.

5) You can laugh as you want, this will not change the reality:
* Sysadmins are a minority of Linux users.
* Distributions like Debian support /etc/network/interfaces with systemd.
* There are sysadmin already using systemd.
* To date there is no enough maintainers against systemd to have successfully make an serious alternative available and ready to use by the distribution.
* Systemd transition is now done by Fedora, Ubuntu and Debian and there are still there.
* Still, a lot of forum get post from 'sysadmin' complaining.

Just did an install in a vm. No. There is no option to choose an init system. systemd is default. If you want to use sysvinit, you have to do it via a pre-install script which basically means, netinstall.

Why just netinstall? The instructions I've seen on the web say: https://wiki.debian.org/systemd#Installing_without_systemd

If not using a preseed file, this can be added to the boot arguments instead by hitting TAB at the boot menu on the desired entry and appending the above preseed line at the end of the boot command.

That doesn't work?

1 vote decided for the systemd takeover in debian.
There was a split 4-4 vote in the debian technical comittie.
Which was then tie-broken by the chair who just happened to be a rabid force-it-down-your-throght supporter.

No, that's not what happened. The vote was: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#6729

          4x D U O V F (bdale, russ, keith, don)
                    F U D O V (steve)
                    U D O F V (colin)
                    F V O U D (ian)
                    U F D O V (andi)

So 4 people wanted systemd, or upstart, or openrc, or even sysvinit but lets stop the boring wrangling,
3 people wanted upstart, or systemd, or openrc, or sysvinit
and one wanted sysvinit, or basicly anything but systemd.

There was no 4-4 split.

As for your insane frothing about SJW's, fuck off you paedophile moron.

"...but only 394 votes ultimately decided Pluto's fate: 237 in favor of demoting the planet and 157 against."

1 vote decided for the systemd takeover in debian.
There was a split 4-4 vote in the debian technical comittie.
Which was then tie-broken by the chair who just happened to be a rabid force-it-down-your-throght supporter.

Then there was a GR with 1 pro-systemd option and 3 or 4 anti-systemd options, so all the anti-systemd votes got split and diluted (together they would have defeated the systemders 60 to 40)

Fuck these people. SJW pieces of shit.
(Same type people banned marrying young girls everywhere, also look at planet.debian.org during the systemd debate: transgender this, women that, bla bla bla. fucking pieces of shit ruin everything good)

---

The "bug" (RFP) has been tagged as "won't fix"
If you aren't a progressive, the debian people
do not want your software, they state this here
in more concise words:
https://bugs.debian.org/cgi-bi...

Opensource isn't about code anymore, it's
about community and beliving and professing
the correct thing. If you do not believe
the correct thing you are removed (example: Ted Walther)
or your software is attacked and removed from its
host (As gpcslots2 was in the past by feminists:
  http://esr.ibiblio.org/?p=1310 )

How do you feel about this change?

http://cdimage.debian.org/cdim...

go there ->

choose your architecture ->
    * i386/amd64/others

choose your download type ->
    * media format (cd, dvd, bd)
    * download method (bt, jigdo, direct iso)

choose your 'default' desktop -->
    * gnome (default, unspecified in filename)
    * kde
    * xfce
    * lxde

download FIRST disc only for your selection.

crickets

Which of:

Bdale Garbee
Russ Allbery
Steve Langasek
Don Armstrong
Keith Packard
Colin Watson
Ian Jackson
Andreas Barth

Is an "ex-RH element"?

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#6729

"First, this is not an imaging system, it's an install system which installs mainly Debian based distributions, based on Fully Automatic Installation (fai-project.org)."

How is this different, then, to Debian Edu? (forget about the fact of "Edu" on its name).

It also aims for a centralized Debian environment, imaging system, centralized configurations, etc. and it's, of course, since it's been in development for some few years, much more mature than your project.

> Both C# and C++ offer low level functionality

Not really. Can you write a device driver in C#? How about a plain DLL? CLR is a VM. Its CPU performance is OK (2-8 times slower than C).

http://benchmarksgame.alioth.d...

But programs written on it have memory requirements that are higher than ones written in plain systems languages. The runtime footprint on the disk is also massive. I don't think you can really make a case that C# is a low-level language. It is not that much more CPU efficient than Java. Mono performance is worse than Java.

http://benchmarksgame.alioth.d...

Of course, CLR is better than dynamic language aka scripting language runtimes. But that's about it.

> Both C# and C++ offer low level functionality

Not really. Can you write a device driver in C#? How about a plain DLL? CLR is a VM. Its CPU performance is OK (2-8 times slower than C).

http://benchmarksgame.alioth.d...

But programs written on it have memory requirements that are higher than ones written in plain systems languages. The runtime footprint on the disk is also massive. I don't think you can really make a case that C# is a low-level language. It is not that much more CPU efficient than Java. Mono performance is worse than Java.

http://benchmarksgame.alioth.d...

Of course, CLR is better than dynamic language aka scripting language runtimes. But that's about it.

The Debian package for libudev1 is built from the systemd source code. Says it right on the page: "Download Source Package systemd".

If your daughter knows how to install Linux, which nowadays isn't very hard depending on the distro, you can always check their site.

Most major distros provide a list of hardware that should be compatible, to avoid having to mess with drivers and such.

Here are a couple of links :
http://www.ubuntu.com/certification/desktop/
http://community.linuxmint.com/hardware
https://wiki.debian.org/InstallingDebianOn

I'm not sure what you mean by "sign packages as a whole" since that wording is somewhat ambiguous, but apt, at least, doesn't sign individual packages. The only signature in place for secure apt is the one placed on the package file listing in the repository. That signed file contains the list of checksums (MD5, SHA1, and SHA256) for each package archive in the repository.

Regarding repeatability: the language is fully deterministic, and compilers have as much of an incentive to be consistent as they do otherwise. If you can't get repeatable builds, then the problem is with your build environment/process more than anything else. Aside from hardware entropy sources, computers are, by design, deterministic, so if you can't reproduce a build it is because you haven't constructed a proper build closure. Certainly there is nothing about C++ that makes builds any more non-deterministic than say, C. Debian actually has a project for this: https://wiki.debian.org/Reprod..., and you may find some helpful information there. You'll notice nothing they've run in to is specific to C++.

Regarding code-to-binary structural coverage analysis. Certainly I can imagine the argument that as you get to higher and higher levels of abstraction, it becomes harder for humans to track all the transformations all the way through to assembly. One solution is to restrict the levels of abstraction you work with. I would argue that is still error prone and you are better off with using theorem prover type automated solutions (and in general, languages built around provability like ML or Coq) rather than manual verification. Even better would be to perform the verification on the compiler itself rather than the code it compiles. That said, C++ compilers do a pretty good job of tracking the origin of each bit of code they generate, which ought to make it easy to have the machine inform you of the origin of any particular code block, and C++ also does a great job of letting the programmer decide what level of abstraction they want to work with and only making the runtime pay for the abstractions they are using. Its stronger type safety also helps ensure that there aren't "hidden" code paths do to programmer error. Of course, optimizers really complicate this, so you may need to turn them off as you mentioned.

Internationalization. That sounds like an old project... one that predates the C++ standard (which means a lot of bad C habits are involved). C++ is actually very well set up for internationalization, particularly because it is so agnostic about how stings are handled. Languages like Python, Perl & surprisingly Ruby have made all kinds of unfortunate decisions around internationalization that make it look like you are fine with internationalization, but it actually blows up in your face. As an example, ICU is probably one of the foremost libraries out there, and its primary language targets are C++ & Java. The C++ target has the virtue that you can pretty much just drop in ICU strings in to a well structured C++ program and all is well in the world, where as the Java one is a bit of a pain to take advantage of (fortunately, Oracle periodically syncs the ICU code in with the JDK, but that means you have to wait for a JDK update to get the latest ICU solution).

This is why I claim it's spyware. Sure, you can turn most of those things off, but the intent of turning them on by default is to capture that information from most users.

you know what I don't use every day? Debian, Do you know why? People like you. I've been using Linux for 20 years and it's people like you that get in the way of progress.

I'm not getting in the way of anything. The kernel is team-maintained and I've explained how this change can be made without my help.

Looks like it's true

Keep in mind the binary log is just the internal format it's stored in for systemd. You can configure rsyslogd just as before to log to plaintext files.

You can configure rsyslogd just as before to log to crippled plaintext files.

FTFY

The guy that said "Sounds like another good reason to not use Google spyware" does not have a Debian email address.

You mean that guy?

I do dislike Chrome and I'm not going to pretend otherwise. Aside from its being spyware (in its default configuration), the Chrome/Chromium developers have previously added requirements that make Chromium unsupportable in Debian 7. We could add this kernel feature now, but I strongly doubt that will be sufficient to keep Chrome/Chromium running on Debian 8 until its EOL.

Please note that I am not NAKing the change, but I'm also not going to be the one to make it happen.

It's for the sake of niceness (well, security and consistency) with locking/unlocking a session. KDE can be run just fine without systemd, just regresses slightly (to how it has acted in all times previously) without systemd.

Frankly, that's the completely sensible way to act towards systemd, and I would be baffled why GNOME didn't follow a similar path if I didn't know that the GNOME and systemd camps are both heavily connected due to Red Hat (the same folks have long talked about the concept of "GnomeOS", and Poettering has called the kernel a mere "implementation detail"; KDE doesn't have the same ties, and has over time gotten less wedded to specific underlying structures and stacks at the same time that GNOME and GTK has gotten moreso).

Personally, I find systemd just a little too complicated, and have run into at least one showstopping issue that, while not a bug in systemd itself, wouldn't really have happened without the level of interlocking complexity that systemd inserts. Distro-creators love it, and it honestly does work well on things like mobile devices (hello there, SailfishOS!) because it makes easier the process of setting up a specific system to be used widely in that exact configuration. But I'm quite apprehensive of how it will interact with more chaotic systems, like normal Linux desktops and servers where many different pieces of hardware and software are installed and all affecting and interacting with systemd. I've installed Debian Jessie on my Raspberry Pi 2 for the sake of toying around with it so I get some experience with it (and immediately ran into the aforementioned issue and created a bug report for it).

Is it still considered "counterfeiting" if the copy is not passed off as being an original?

Since we need an example to work with, let's say that there's a popular brand of buttplugs. Let's call them "Systemd Buttplugs", and the genuine ones contain a very recognizable logo on them.

And let's say that some 3D printing enthusiast examines a genuine one, but then 3D prints his own buttplug made of the same materials, and with the same dimensions, but without the official logo on it. It's identical in every respect, except for the missing logo, and he doesn't otherwise represent it as being an actual "Systemd Buttplug". He only makes one copy, and it's for his own personal use (or maybe for use with a couple of buddies from his local Linux user group).

Would this 3D printed copy be considered a "counterfeit", even though it isn't being passed of as being an original "Systemd Buttplug"? Would it just be considered a "replica"?

... so I took a blow-torch to my car to remove the hardpoint to which one can attach a towing hook.

Clearly the presence of the hardpoint is all part of the caravan club's conspiracy.

Having removed the hardpoint I can rest easy that I won't find myself suddenly towing a caravan.

OK, so the structural integrity of the chasis is somewhat compromised, and I'll probably end up losing control of the vehicle at some point as a result of that, but the risk is totally worth it to avoid the risk of caravan infection.

I really don't know what the designers were thinking. How could they inflict this creeping caravanism on me by making the structure at the back of my car confom to caravan-club standards?

=-=-=-

As for libsystemd0, for a sane view read:
  https://lists.debian.org/debia...

Unlikely, it is a minority of malcontents who are upset about SystemD who have created an echo chamber of half truths and outright lies.

Speaking of outright lies... where is your proof that only a minority of people are unhappy about SystemD?

You do realize RedHat (the distro running systemd for the longest) has reported their subscriptions going up for the last several quarters? Meanwhile we have people who are making a lot of noise about leaving but never actually do. (Distrowatch is showing interest in *BSD as dropping) We have a Debian fork claiming to be a bunch of "veteran admins" without naming any of them and a mailing list of people who like to argue more than they like actually doing anything. So where are all of these upset people going?

Let's examine our current environment: Slashdot.

Here there are more people who are deeply against SystemD than there are for SystemD. If you look at the arguments against, there are numerous well-reasoned arguments that nobody from the SystemD has even begun to address.

Well reasoned like the post I was replying to? It managed a "Score 5: Informative" despite not having any arguments that were actually true.

The Slashdot echo chamber is what annoys me the most about all of this. I see posts like "SystemD is Monolithic" (it isn't) "SystemD includes an NTP and DHCP server in PID 1(They are optional and don't run as PID 1). Or my all time favorite: "SystemD" is designed for desktops and makes server administration harder" When the reality is that SystemD was designed with some of the more complicated server setups in mind and the speed improvement on the desktop was mostly an accidental byproduct. The only actual valid complaint I have seen so far is about the binary logs but they are easy to bypass and even with journald doing mostly nothing, the whole thing uses less RAM and disk space than the init system it is replacing.

If you look at the arguments for, they do not seem terribly convincing, such as "this is a better way" or "startup is faster in the best case".

Naturally, this is plumbing and boring by nature. "Works best for this case" is actually a good reason for doing it In the meantime, the old system was a bug ridden mess. I mean really, I had until recently some servers that need a partial filesystem mount followed the network followed by GlusterFS followed by Apache. Care to guess how well that works in a default Debian stable install?

I mean really, even if the damned thing did what it claims to do, the specific implementation is clearly lacking. So I have to ask, why exactly are you so gung-ho for SystemD? Surely you should be gung-ho for a solution, not a specific method. No?

I am not so much pro SystemD as much as I am anti FUD. I am annoyed that I let the slashdot crowd actually made me worry about my future as a Linux admin until I researched for myself what the facts were .In the end, I wouldn't be shocked if SystemD ended up being a good proof of concept and replaced with something else. In the meantime, it solves more problems than it creates and manages to be better than the alternatives.

Debian switched because they were losing market share on larger systems that the current init system only handles under extreme protest.

What are you talking about? losing market share? larger systems? Which systems? How was market share measured? Show me where the Debian project claims this. You sound like an MBA.

It's right in their "Why SystemD" document. " But the real problems arise on big server setups, where Debian is losing ground because of its antiquated init system. On these systems, you need fine service management, process monitoring, reliable dependencies, complex device setups and proper event handling."

You should not use it. Developers should use it. If you're an end-user use what comes with your distribution.

You're looking for a reason to be afraid and/or outraged. You must be, because almost all of the Linux distros have seen sufficient technical advantages to systemd to switch to it. If you haven't heard about these technical reasons, you're self-selecting against this information. It's okay, everyone does it, but in this case the majority of technical experts are for systemd, and that's prima facie evidence that the opposing information is lower-quality. Be aware of what your influences are.

http://0pointer.de/blog/projects/why.html

https://wiki.debian.org/Debate/initsystem/systemd

Init is a misnomer; we're talking about the thing that starts and manages services and runlevels. Init is part of that. As a service manager, sysvinit fails badly. Starting a service on linux involves double-forking and writing your process number to a file, and hoping that file is still accurate when you want to kill the process. See here for an example. All of those steps must be implemented by every service, and the logic for doing so is duplicated across every service — hopefully correctly. There are quite a few things that can cause the pidfile not to be accurate, at which point init can't do anything with it. Also, because sysvinit is just a collection of scripts, [a] they're all run in sequence, and [b] when problems happen, the script exits with a non-zero return value. If you need anything more than a non-zero return value you'd better roll it yourself.

Cgroups were invented to fix this, because you need kernel cooperation to track processes accurately. Systemd was invented to manage services using cgroups, and is heavily influenced by OSX's service manager. For a more thorough investigation about the rationale behind systemd's features, collectively and severally, please see Poettering's blog (https://0pointer.de/).

Sysvinit is really good for people that need to script every aspect of their OS. Some of these people are sysadmins who think that scripting is actually their job. Some of these people think that scripting is what Unix is all about. These people are generally bad programmers who forget that Unix is also about cleaning up scripts and rewriting them in C. Init scripts are easier to debug, but most other OSes seem to get by without anyone needing to debug init scripts.

Also, if you've ever worked with chroots, check out systemd's containers; they are a major feature and quite nice to use.

Tempest in a tea pot really: I had the very same issue with Jessie and a little googling around quickly found the issue and a solution (for example here: https://lists.debian.org/debia...).

In short, if one installs (installed?) Debian Jessie from a USB key the installer would add an entry in /etc/fstab for the key. Now the automounting of USB keys for the currently logged user is normally taken care of by udev, who does things properly. But for backward compatibility if there's a /etc/fstab entry udev bows out and let the legacy system handle the key, and that's where one end-up with a USB key mounted as root instead of as the user. Fix: remove the useless /etc/fstab entry. As this has been discussed already on the Debian user mailing list it's likely been fixed in the install process by now (not check, will try with a new laptop next week).

All in all: a small installation process glitch in the testing distribution, so still beta. But let's not waste such an opportunity to rant on how much the old times were betters, and young ones are hopeless. I guess the real issue is that early Linux users (me included) are getting older, and more adverse to changes.

Thanks for the feedback. My conclusion is, that I'm going to look into a few variants of solutions, one main track being ready-made VMs of my favourite installation, the other being Debian FAI. ... I'm pretty sure I'm sticking with Debian for this task, so FAI is probably the way to go. I will look into Puppet aswell, although I'm not sure yet if it's usefull for speeding initial installation and setup of individual systems.

I wasn't aware of the Turnkey Linux stuff, so thanks for that tip aswell.

I also understand the notion that setup and configuration is bascially our job as devs and IT experts, nevertheless, I suspected that the strong presence of LAMP might have brought about something ready-made that speeds up the task a little. ... I'll start rolling my own solution and perhaps put it online some day for others to use. ... Scratch your own itch, they say, don't they?

Once again, thanks for the feedback.

Actually that's pretty wonky. Please file a Debian bug report.

I remember several.

There were more than several. But only rarely a regression so severe that it crippled the system beyond repair. IIRC I only once had problems during Perl 5.10 rollout and that was relatively easy to fix, though I had to wait for about a week before all the core packages were updated for the new version of Perl and apt-get finally started working again.

But again, that is a minor issue: one can always "predict" the breakages, since they happen only during "transitions" for which Debian has a tracker.

No, it's not "supposed to break"

https://wiki.debian.org/Debian...

The Unstable repositories are updated every 6 hours.

Some times are safer than others to upgrade packages in unstable, as at any given time, one or more OngoingTransitions may render some packages uninstallable, or release critical bugs may affect key packages.

Nearly every single time Debian has made major plumbing changes, by for example upgrading or changing major boot packages that run by default, they've broken testing. Read the archives and you'll even find times they've corrupted peoples drives. Maybe you should be aware of what you are using, for gods sake they have a warning when you install testing that you run the chance of total data loss and having to format and reinstall.

But of course you know better than the Debian Developers!

but Perl is that slightly chubby girl with the wry smile that is always reliable and willing to go to the dance with you.

Perl still runs fast.

And, before running, detects typing mistakes in variables when you "use strict;" (which, of course, your editor automatically inserts). Python has this little problem that such mistypings are still a run-time error. When the code that uses them executes. Oh the horror.

A patch is different from a OS level upgrade. One is just updating *ONE* component. The other is an entire OS update.

If you can't understand why one would be easier than the other, then maybe slashdot isn't the right site for you.

As for Debian 6.0 - https://www.debian.org/News/20...

I've used Debian for years now, but its quality is getting really bad these days. Things have gotten particularly bad since the switch to systemd.

Some of the bugs that Debian suffers from now are unbelievable. There was one bug that broke the WINE launch script, for example. It made it impossible to use WINE to run Windows programs.

When I first heard about that bug, I couldn't believe it. How could a bug like that even get through? It was blatantly obvious. Trying to run a Windows program using WINE would have shown it was broken! Didn't the package maintainer try that most basic of tests while preparing the new version?

I don't expect perfection from Debian, but I do expect a minimal level of quality, and that particular bug is just plain inexcusable.

The saddest part of all of this is that Debian is actually one of the better distros out there! The others are often more seriously broken in many other ways.

I applaud Linus for caring so highly about quality, but it does not do much good to have a robust kernel if the distros are broken in idiotic ways.

When you can't log into your damn bank because it's said that IE6 is too old, your system is end-of-life. That's the end of it. Because to fix it, bodge it, fake it, or upgrade it costs more than just following the rest of the world in their lowest-accepted technology standard.

You can just install another browser that is more secure than ANY version of IE anyway, like Firefox or Chrome
Even better, install a secure OS : https://www.debian.org/distrib...

Yes. And the problem is that VB is MS only. It is a vendor lock in. What about stuents that have a Mac or Linux at home? He chains them to MS.

On Debian 7:

$ uname
Linux
$ vbnc
Visual Basic.Net Compiler version 0.0.0.5943
Copyright (C) 2004-2010 Rolf Bjarne Kvinge. All rights reserved.

Error : VBNC2011: No files to compile! Cannot do anything!
Compilation took 00:00:00.2141430

https://packages.debian.org/je...

Also, the new Microsoft .NET compiler (Roslyn) is open source.

I'm bummed that Ian's GR concerning init system equality failed

Why? What that GR said was that packages that didn't support all init systems would be removed from Debian -- i.e. if it had passed Xfce4 would simply be removed.

This is the GR:
      https://www.debian.org/vote/20...

the intent of which was to insure that alternate init systems continued to work, not to remove packages that didn't support that. Making a bug RC could potentially cause a package to be removed if the bug was ignored and unfixed, but any DD can NMU the package to fix an RC bug at any time, so packages like Xfce4 being removed as a result of an init system RC bug is fairly unrealistic IMHO.

It has basic tab completion by default. It doesn't have bash-completion. http://bash-completion.alioth....

0) Okay, I agree that I should have phrased that differently. Note that I didn't use a pejorative phrase; I didn't say something like "morons too stupid to understand the greatness of SystemD" or whatever. I really only meant to say "some people who strongly disapprove of SystemD do not want it involved in logging at all."

1) I hope you didn't intend to lump me in with "systemd people" because I'm not one. I am an interested observer looking in from the outside. To the extent that I care about Linux and its future, I care about SystemD; I've been trying to understand how good or bad it is.

But the vast majority of the criticism I have read of SystemD has been just opinion-based flaming. To read most of the posts on Slashdot, there must not be anything good about SystemD and the people who choose it must be deluded or fools or something. I wanted to push past that and understand why smart people might not reject SystemD.

for those of us that use 'sed' and 'grep'

I'm quite skilled with grep so I can query plain-text files just fine, but I'm not opposed to SystemD making a binary log with an index for its own purposes.

If you set up rsyslog or whatever, you will still get a plain-text log file, and you have the option to simply ignore SystemD's own log file.

Windows style 'Services' (your word)

No, don't lump me in as a "systemd person". And don't assume that I'm your enemy or something.

And don't ask "how are they forcing" again, that isn't helpful when I can't get just turn the package off and sysv init on.

In Debian "jessie" you can do just that.

https://wiki.debian.org/systemd#Installing_without_systemd

If it was me, then I'd just use Debian or Ubuntu Server and install sysvinit and remove systemd.
Relevant links:
  How to remove systemd from Debian
  Debian list post

I've got 64-bit Mint 17.1 Cinnamon on an older (Ivy Bridge-powered) Lenovo Ideapad Yoga 11s. Everything worked immediately except the wireless*, which was easy enough to fix after I downloaded one third-party package plus dkms to auto-rebuild the module during kernel upgrades.

Cinnamon's UI isn't designed around touchscreens, but it works with them, much like MATE. I prefer the good old keyboard and touchpad myself.

https://wiki.debian.org/Instal...

* and some fancy power management stuff that's handled by a utility on the Windows side, such as restricting the battery to 60% charge to prolong life. It can still be toggled in the UEFI.

Debian rejects game due to authors opinion on women.

A properly licensed opensource casino video game was
recently posted to the debian bug tracker as a request
for packaging, as is the standard method for pursuing
such things in debian.

The bug was quickly closed, tagged as "won't fix"
The reason given by one of the debian developers
alluded to the authors past anti-feminist remarks:

https://bugs.debian.org/cgi-bi...

The piece of software in question is licensed
under the GPL and is one of the only of it's
kind for linux (ascii-art console slot machine software)

Is professing progressive politics now a hard requirement
for being allowed to contribute to free software projects?

Debian rejects game due to authors opinion on women.

A properly licensed opensource casino video game was
recently posted to the debian bug tracker as a request
for packaging, as is the standard method for pursuing
such things in debian.

The bug was quickly closed, tagged as "won't fix"
The reason given by one of the debian developers
alluded to the authors past anti-feminist remarks:

https://bugs.debian.org/cgi-bi...

The piece of software in question is licensed
under the GPL and is one of the only of it's
kind for linux (ascii-art console slot machine software)

Is professing progressive politics now a hard requirement
for being allowed to contribute to free software projects?

Install/configure http://wiki.debian.org/iptable... and you'll be safe

Because SOCIAL JUSTICE.

Debian has been taken over by feminists and SJWs.

Debian rejects game due to authors opinion on women.

A properly licensed opensource casino video game was
recently posted to the debian bug tracker as a request
for packaging, as is the standard method for pursuing
such things in debian.

The bug was quickly closed, tagged as "won't fix"
The reason given by one of the debian developers
alluded to the authors past anti-feminist remarks:

https://bugs.debian.org/cgi-bi...

The piece of software in question is licensed
under the GPL and is one of the only of it's
kind for linux (ascii-art console slot machine software)

Is professing progressive politics now a hard requirement
for being allowed to contribute to free software projects?

I was just quoting the (ex-)maintainer of the systemd, from his e-mails from the CTTE discussion.

Without source or citation. I think your representation of what was said is rather biased.

Debian feedback would be submitted to mainline - but if it is rejected, he wouldn't even carry a custom Debian patch for it, because he doesn't want to deviate from the mainline. And he, as the maintainer of the systemd, would not consider it a bug. As such somebody else would have to fix somewhere else.

If it isn't a bug, why patch it? Sure, some people have tried to drop some turd patches into systemd, eg. ripping out security features in order to support some obscure glibc variant. The right thing of course is to patch the glibc variant to support the proper security functions, not patching systemd.

No package maintainer wants to support non-trivial, non-mainline patches without very good reasons. The whole point of open source software, that as many people as possible can share and enjoy improvements, so patches should go upstream as fast as possible. Maintaining non-trivial, non-upstream patches can also be a real problem when backporting security fixes, and may introduce patch specific bugs too.

If you are willing to grep through the 1K emails - you would definitely find that being repeated several time.

I have actually read most of them at the time, and I still think you are misrepresenting the systemd maintainers.

Here is a Debian specific patch that predates Debians adoption of systemd as default init-system:
http://cgit.freedesktop.org/sy...

It's obviously not Debian specific.

It is very obviously a distro specific part of systemd: Debian was added to the list where Fedora and Arch were already present.

Huh? The main point is that systemd mainline accepts Debian (and distro) specific patches if it is unavoidable. Despite the many claims to the contrary, the systemd developers do care about feedback and have many different distro developers with commit access. If you got a good user case, chances are good that a distro specific patch will be accepted. And having the patch going into the upstream repo is much better than carrying it as a separate distro patch.

In short, Debian developers where taking part in creating systemd long before Debian discussed making systemd the default init system. So they knew what they where doing when selecting systemd over Upstart (the CLA was enough to discount it), and the latest GR have confirmed that the vast majority of Debian developers firmly backs systemd as the default init-system.

Sure, the main branch of systemd wants to have as few distro specific patches as possible, but they do accept them if there is no other solution.

I was just quoting the (ex-)maintainer of the systemd, from his e-mails from the CTTE discussion.

Debian feedback would be submitted to mainline - but if it is rejected, he wouldn't even carry a custom Debian patch for it, because he doesn't want to deviate from the mainline. And he, as the maintainer of the systemd, would not consider it a bug. As such somebody else would have to fix somewhere else.

If you are willing to grep through the 1K emails - you would definitely find that being repeated several time.

Here is a Debian specific patch that predates Debians adoption of systemd as default init-system: http://cgit.freedesktop.org/sy...

It's obviously not Debian specific.

It is very obviously a distro specific part of systemd: Debian was added to the list where Fedora and Arch were already present.

If you're a male, don't even bother.
Only women and their supplicants allowed.

Debian rejects game due to authors opinion on women.

A properly licensed opensource casino video game was
recently posted to the debian bug tracker as a request
for packaging, as is the standard method for pursuing
such things in debian.

The bug was quickly closed, tagged as "won't fix"
The reason given by one of the debian developers
alluded to the authors past anti-feminist remarks:

https://bugs.debian.org/cgi-bi...

The piece of software in question is licensed
under the GPL and is one of the only of it's
kind for linux (ascii-art console slot machine software)

Is professing progressive politics now a hard requirement
for being allowed to contribute to free software projects?

FUCK THIS WOMANS SOCIETY

Debian does not use a "wheel" group. Some Debian-derived distros might, but Debian itself doesn't. I recently installed a Debian server, and it is not how you describe: a root password was set during install, and there is no wheel group. This was from the official Debian 7 "wheezy" installer.

But unless you're doing something that's waiting for disk input and output or network input and output, the difference isn't 4%. The micro-benchmarks at the Great Computer Language Shootout page are a simple starting point. For Java vs. C++, for some reason the chart (section 2) doesn't show memory difference correctly. The measurements section (section 3) does - Java is about 2x slower than C++ in most of the benchmarks, but only comes within 2x of C++ for memory usage in a few places, in most other micro benchmarks the memory difference is higher, even 20 times higher. ( http://benchmarksgame.alioth.d... )

Debian rejects game due to authors opinion on women.

A properly licensed opensource casino video game was
recently posted to the debian bug tracker as a request
for packaging, as is the standard method for pursuing
such things in debian.

The bug was quickly closed, tagged as "won't fix"
The reason given by one of the debian developers
alluded to the authors past anti-feminist remarks:

https://bugs.debian.org/cgi-bi...

The piece of software in question is licensed
under the GPL and is one of the only of it's
kind for linux (ascii-art console slot machine software)

Is professing progressive politics now a hard requirement
for being allowed to contribute to free software projects?

------

Debian developers also threatened author with lengthy imprisonment, denied existence of author's contributions

Previously a debian developer, Erich Schubert, claimed that the author of gpcslots had never
contributed anything to opensource, was corrected, replyed to the corrections,
and then deleted the corrections and left up his false claims.
Author has contributed gigabytes of media to opensource, years of programming
work, and has been involved in numerous projects.
http://www.vitavonni.de/blog/2...

Another debian developer, Josselin Mouette, (while bragging that he, JM, had successfuly
campaigned to ban prostitution in france, have Johns arrested, and had run
mafias out of the country) told the author that he was going to have him
arrested by the FBI (van'd) because the author suggested there was no sin
in marrying young girls (and cited a bible verse in support of that).
http://np237.livejournal.com/3...

Debian rejects game due to authors opinion on women.

A properly licensed opensource casino video game was
recently posted to the debian bug tracker as a request
for packaging, as is the standard method for pursuing
such things in debian.

The bug was quickly closed, tagged as "won't fix"
The reason given by one of the debian developers
alluded to the authors past anti-feminist remarks:

https://bugs.debian.org/cgi-bi...

The piece of software in question is licensed
under the GPL and is one of the only of it's
kind for linux (ascii-art console slot machine software)

Is professing progressive politics now a hard requirement
for being allowed to contribute to free software projects?