Slashdot Mirror

Then which distro should I use instead of Xubuntu on a Transformer Book? Google asus transformer book linux suspend brought this disappointing result: "suspend not working at all" and "Reboot doesn't work either, seems like acpi is broken." Likewise Debian has "Sleep / Suspend: Error (Couldn't get it working)".

It's a symlink into a systemd managed ntwork configuration repository, until the user breaks the link deliberately or accidentally with a text editor or configuration tool like puppet, cfengine, Chef, BladeLogic, Tuttle, or anyone else's homebrew server configuration tools, and then it *stays* broken permanently. See https://wiki.archlinux.org/ind...

Once gain, Mr. Pottering fails to understand the File System Hierarchy and why you don't dink with other people's stable tools.

https://wiki.archlinux.org/ind...

just wanted to run a service
i wrote with the ulimit for the number of available files set to be a larger than
default value?

you know it took me a fucking day to figure out how, and it still required a reboot
after install?

You need to upgrade your goole-fu, or just "man systemd.exec".

LimitCPU=, LimitFSIZE=, LimitDATA=, LimitSTACK=, LimitCORE=, LimitRSS=,
              LimitNOFILE=, LimitAS=, LimitNPROC=, LimitMEMLOCK=, LimitLOCKS=,
              LimitSIGPENDING=, LimitMSGQUEUE=, LimitNICE=, LimitRTPRIO=,
              LimitRTTIME=
                      These settings control various resource limits for executed
                      processes. See setrlimit(2) for details. Use the string infinity to
                      configure no limit on a specific resource.

i gave up on trying to enable coredumps

How hard did you try? https://wiki.archlinux.org/index.php/Core_dump

systemd's default behavior is to generate core dumps for all processes in /var/lib/systemd/coredump. This behavior can be overridden by creating a configuration snippet in the /etc/systemd/coredump.conf.d/ directory with the following content[1][2]: /etc/systemd/coredump.conf.d/custom.conf

[Coredump]
Storage=none

Sounds like a job for Cron.

Better yet, systemd/Timers: https://wiki.archlinux.org/ind...

No surprise about tcpd (aka Wietse Venema's TCP wrapper utilities) which has not been updated since its last release in 1997.

It should just be removed from all Linux distributions just as Arch did in 2011: https://www.archlinux.org/news...

Use something, anything else rather than this practically stone age software.

I hope you are being sarcastic, because that tool just works and still has its use. Even if it is rare that it is needed and its last update was pretty long ago. It is small and feature complete for now. There will be an update if someone finds a bug in the source. But hey. let's throw all small and stable programs out or at least add some new feature from time to time.

No surprise about tcpd (aka Wietse Venema's TCP wrapper utilities) which has not been updated since its last release in 1997.

It should just be removed from all Linux distributions just as Arch did in 2011: https://www.archlinux.org/news...

Use something, anything else rather than this practically stone age software.

systemd isn't even fucking related

Systemd is like a car analogy.

I'd call you arch users

Why is that? Archlinux was one of the first distros to shove systemd down its users' throats.
By the way, for those looking for a replacement there's OpenRC. It works pretty well. Boot times are longer, though, which means it takes a few seconds more to boot every few months.

This is caused by the default "swappiness" value of 60. Try setting it to 1 or running without a swap partition if you have enough RAM.

https://wiki.archlinux.org/ind...

The default of 60 sacrifices UI responsiveness for program performance and having it continue to be the default setting even on every distro that is specifically aimed at desktop use is a bit baffling.

Use of TRIM fights the deleterious effect of write amplification on lifespan, as well as reducing degradation of performance over time. Why does that "make no sense" for individual users?

There are two strategies for using TRIM.

The first one is "discard" in the mount options, which causes the drive to be informed via the TRIM command at the time a block is freed (file erased). The second strategy runs a utility (fstrim) periodically - for example, once a day - to TRIM all the blocks freed since the last time.

The first strategy somewhat slows down each delete in normal operation, and is considered to be dangerous. For this reason the second strategy is considered to be preferable. It is not clear to me why grouping the TRIMs and executing the groups infrequently is considered safer. But I have used the second strategy for a long time on my M500 SSD and never discovered any corruption.

References: 1, 2, 3

There's very little good reason to use 'discard' on Linux

Care to elaborate on that? My bible says that discard is the first choice, fstrim when that isn't applicable for whatever reason. Bear in mind that I use Linux mostly as a desktop OS, so whatever caveats there may be in server use do not affect me.

Now if you just need a simple static address I would suggest to use systemd-networkd: https://wiki.archlinux.org/ind...

Oh, neat. So instead of writing two scripts (all w/ bashisms), a configuration file and a unit file, the "next best" way is to run yet another 13.000-lines C program (cat src/network/network[cd]*.[ch] | wc -l).

I can't even tell if you're trolling or just a good example of demonstrating what's wrong with systemd mindset.

I don't understand you, really. The procedure you mentioned was the bare minimum if you don't want to use any helper scripts or applications

Except for the mentioned helper scripts and the whole bloated infrastructure of systemd, sure.

and is almost identical to what you need with system V init to get the same functionality: the configuration file and the two scripts are absolutely not related to systemd at all.

How aren't they related to systemd? I'm not following, I think.

The difference is that with system V init you need to write a script with a start) and stop) method while with systemd you have to write a service file. At the end this is exactly the same number of files, so what your problem ?

So you see how pointless it is?

systemd-networkd is only an alternative. Personally I largely prefer C code over scripts, mainly because C code projects tend to be adopted by many distributions while scripts tend to remain specific to each distribution. The systemd vs system V story is an very good illustration of this difference.

Disclaimer: I have a ton of experience in C; i really like the language. But would you please think of debugability? Quickly analyzing and fixing a bug in a script means editing that script. Fixing a bug in a component that is written in C, means a) identifying what part failed in the first place, checking out the entire project, getting it to compile (which tends to include a ton of build time dependencies), of course don't forget to compile with debug symbols. Then either install the debug version, which sucks, or put it somewhere else and hope the part you're fixing doesn't use the non-debug version. And that is even ignoring the actual effort about fixing the actual bug...
A shell script? add a ``set -x'' to find out what's going wrong, edit to fix, which is usually no problem for someone who knows their shell.

You see, I already have two good solutions and this little experimental journey into the Arch world just made clear that if I hadn't moved to the BSDs back in the day, I'd do it now. Thanks, though.

So why did you post on a Ubuntu systemd specific discussion if you use *BSD and have only tried Arch ? AFAIK Debian still provides support for /etc/network/interfaces with systemd so basically nothing changed for the users.

Perhaps because I had some impressions with a journey into the systemd world to share? I do manage a few hundred Debian machines at work, so i'm not a complete stranger in the linux world.

Why do you put whitespace in front of question marks?

Now if you just need a simple static address I would suggest to use systemd-networkd: https://wiki.archlinux.org/ind...

Oh, neat. So instead of writing two scripts (all w/ bashisms), a configuration file and a unit file, the "next best" way is to run yet another 13.000-lines C program (cat src/network/network[cd]*.[ch] | wc -l).

I can't even tell if you're trolling or just a good example of demonstrating what's wrong with systemd mindset.

I don't understand you, really. The procedure you mentioned was the bare minimum if you don't want to use any helper scripts or applications and is almost identical to what you need with system V init to get the same functionality: the configuration file and the two scripts are absolutely not related to systemd at all. The difference is that with system V init you need to write a script with a start) and stop) method while with systemd you have to write a service file. At the end this is exactly the same number of files, so what your problem ?

systemd-networkd is only an alternative. Personally I largely prefer C code over scripts, mainly because C code projects tend to be adopted by many distributions while scripts tend to remain specific to each distribution. The systemd vs system V story is an very good illustration of this difference.

You see, I already have two good solutions and this little experimental journey into the Arch world just made clear that if I hadn't moved to the BSDs back in the day, I'd do it now. Thanks, though.

So why did you post on a Ubuntu systemd specific discussion if you use *BSD and have only tried Arch ? AFAIK Debian still provides support for /etc/network/interfaces with systemd so basically nothing changed for the users.

Then you want systemd. As I mentioned before, the sysvinit start scripts are huge, complicated and error prone (the loop in Apache init script). In systemd all you have is a 17 lines file for Nginx: https://projects.archlinux.org... [archlinux.org]

Your argument is a bit flawed. You can actually bootstrap apache with a single command (apachectl start) you can include in /etc/rc.local or similar startup script. For nginx, it gets a bit more complex, as no deamon control program exists (while you can actually do most stuff by using the -s modifier). So, comparing apples to apples, the apache22 init script in FreeBSD has around 190 lines, and nginx's ~140, including comments and dependencies. The scripts are quite easy to understand and show how to put everything in place. Ever tried to run multiple copies of the same program simultaneously with completely different parameters? With a shellscript, is trivial to do so.

systemd adds a lot of extras, and does not take anything away. It adds, a) info on whether the service was started, b) automatic restart of crashed services, c) journald, d) limit resource usage per service, e) simple and powerful service configuration files, f) inter service dependencies management (start Thin only if Nginx is started, or start MySQL after Apache) g) a lot of tools that were missing like systemd-ask-password.

...None of them are useful to me. a) Info if the service is started or not is standard in every rc.d/init.d system I know, via the service command or other methods. b) the LAST thing I want is automatic restart of crashed services. I want to know it crashed, and investigate why (automatic restart easies the process of remote code execution in network daemons). c) journalD adds nothing useful. If I wanted my logs in a database, pretty much half of the loggers available have that option. d) this already exists in (every?) unix system. Its called process accounting and limits. Dependency managent is a solved problem - either via explicit ordering as in traditional linux systems, or explicit dependency enumeration in FreeBSD/NetBSD. If you think this is a cool feature, you've been living under a rock for the past decade or so. g) systemd-ask-password is a prime example of a cool feature that has *nothing* to do with the init process, so it should not be part of it.

And systemd does not take anything away from you. You can still use all your old school tools and your old style logging, and even the old sysvinit scripts.

Theoretically. In practice, it overrides the way sysvinit works, and you need to explicitly re-enable it.

"but if not, why the f*ck is it taking control over MySQL initialization? " What do you mean by that? It starts the service and watches the service that it is really started, and it gives you info that it is started or it didn't started or it crashed. For example, on my laptop:

Try it with MySQL. Your output actually has useful info, in MySQL's case, it doesn't, as systemd isn't capturing the program's log. And what if I had multiple mysql copies running?
In the end, systemd adds nothing to the existing process. Maybe stuff boots faster on a laptop, but I don't really care about startup times. I care about reliability and being able to fix stuff when it breaks. Again, systemd stands in the way, its not a help. If you feel intimidated by a 9Kb shellscript file, It may be suitable for you, but it's not for me. I prefer to dig around a small shellscript file than to have to read manpages and google stuff dispersed on the internet.

Well, there is probably a lot of even more complicated methods.

I'm sorry to hear it.

Now if you just need a simple static address I would suggest to use systemd-networkd: https://wiki.archlinux.org/ind...

Oh, neat. So instead of writing two scripts (all w/ bashisms), a configuration file and a unit file, the "next best" way is to run yet another 13.000-lines C program (cat src/network/network[cd]*.[ch] | wc -l).

I can't even tell if you're trolling or just a good example of demonstrating what's wrong with systemd mindset.

I hope this one is simple enough for your use case.

No, it's not; and more to the point, I don't have a real "use case". As said:

The other day I had a spare machine sitting around [.........] [and then] I nuked [it]

You see, I already have two good solutions and this little experimental journey into the Arch world just made clear that if I hadn't moved to the BSDs back in the day, I'd do it now. Thanks, though.

Well, there is probably a lot of even more complicated methods.

Now if you just need a simple static address I would suggest to use systemd-networkd: https://wiki.archlinux.org/ind...

I hope this one is simple enough for your use case.

I'm completely stumped, so I welcome any suggestions at this point.

I suppose you've checked out https://wiki.archlinux.org/index.php/Power_management

"It's eating the ACPI events from the ACPI sleep button and refuses to acknowledge that they exist and won't send them anywhere." - have you done anything about reporting as it not every computer labels ACPI events in the same way? have a read of this https://wiki.archlinux.org/ind... - configuration section to see if helps

printf 'up\n192.168.1.42/24 media autoselect\n' >/etc/ifconfig.xyz0
printf 'defaultroute=(gateway addr)' >>/etc/rc.conf

I also faintly remember how to do that on non-systemd Linux, for instance in Debian it's adding 2-3 lines to /etc/network/interfaces.

So far, so good. Now, let's see how this is done when systemd is involved, the following is copypasted right from the Arch wiki

Persistent configuration on boot using systemd
First create a configuration file for the systemd service, replace interface with the proper network interface name:

/etc/conf.d/net-conf-interface

address=192.168.1.2
netmask=24
broadcast=192.168.1.255
gateway=192.168.1.1

Create a network start script:
/usr/local/bin/net-up.sh

#!/bin/bash
ip link set dev "$1" up
ip addr add ${address}/${netmask} broadcast ${broadcast} dev "$1"

[[ -z ${gateway} ]] || {
ip route add default via ${gateway}
}
Network stop script:
/usr/local/bin/net-down.sh

#!/bin/bash
ip addr flush dev "$1"
ip route flush dev "$1"
ip link set dev "$1" down

Make both scripts executable:
# chmod +x /usr/local/bin/net-{up,down}.sh

systemd service file:
/etc/systemd/system/network@.service

[Unit]
Description=Network connectivity (%i)
Wants=network.target
Before=network.target
BindsTo=sys-subsystem-net-devices-%i.device
After=sys-subsystem-net-devices-%i.device

[Service]
Type=oneshot
RemainAfterExit=yes
EnvironmentFile=/etc/conf.d/net-conf-%i
ExecStart=/usr/local/bin/net-up.sh %i
ExecStop=/usr/local/bin/net-down.sh %i

[Install]
WantedBy=multi-user.target
Enable and start the unit network@interface, replacing interface with the name of your interface.

Source
Hilarious, right? It's so simple! And it totally does away with those pesky shell script, yet in order to do something as simple as configuring a static IP, the user is told to create two shell scripts, apart from the systemd "unit file" and the file that contains the actual address.
At that point I nuked the machine and called myself lucky for not having to cope with this shit.

Your comment has too few characters per line (currently 24.9).
Please ignore everything below; /. wouldn't let me comment without it

The log file is expected to reside in the /var/run directory, which may not be writable very early in the boot sequence, and which is erased a little later in the boot sequence. We therefore avoid writing to the file until we believe it's safe to do so. We also assume that it's reasonable to always append to the file, never truncating it. Optional argument $1 may be "OK" to report that writing to the log file is expected to be safe from now on, or "FORCE" to force writing to the log file even if it may be unsafe. Returns a non-zero status if messages could not be written to the file. rc_postprocess Post-process the output from the rc_real_work() function. For each line of input, we have to decide whether to print t

printf 'up\n192.168.1.42/24 media autoselect\n' >/etc/ifconfig.xyz0
printf 'defaultroute=(gateway addr)' >>/etc/rc.conf

I also faintly remember how to do that on non-systemd Linux, for instance in Debian it's adding 2-3 lines to /etc/network/interfaces.

So far, so good. Now, let's see how this is done when systemd is involved, the following is copypasted right from the Arch wiki

Persistent configuration on boot using systemd
First create a configuration file for the systemd service, replace interface with the proper network interface name:

/etc/conf.d/net-conf-interface

address=192.168.1.2
netmask=24
broadcast=192.168.1.255
gateway=192.168.1.1

Create a network start script:
/usr/local/bin/net-up.sh

#!/bin/bash
ip link set dev "$1" up
ip addr add ${address}/${netmask} broadcast ${broadcast} dev "$1"

[[ -z ${gateway} ]] || {
ip route add default via ${gateway}
}
Network stop script:
/usr/local/bin/net-down.sh

#!/bin/bash
ip addr flush dev "$1"
ip route flush dev "$1"
ip link set dev "$1" down

Make both scripts executable:
# chmod +x /usr/local/bin/net-{up,down}.sh

systemd service file:
/etc/systemd/system/network@.service

[Unit]
Description=Network connectivity (%i)
Wants=network.target
Before=network.target
BindsTo=sys-subsystem-net-devices-%i.device
After=sys-subsystem-net-devices-%i.device

[Service]
Type=oneshot
RemainAfterExit=yes
EnvironmentFile=/etc/conf.d/net-conf-%i
ExecStart=/usr/local/bin/net-up.sh %i
ExecStop=/usr/local/bin/net-down.sh %i

[Install]
WantedBy=multi-user.target
Enable and start the unit network@interface, replacing interface with the name of your interface.

Source
Hilarious, right? It's so simple! And it totally does away with those pesky shell script, yet in order to do something as simple as configuring a static IP, the user is told to create two shell scripts, apart from the systemd "unit file" and the file that contains the actual address.
At that point I nuked the machine and called myself lucky for not having to cope with this shit.

Your comment has too few characters per line (currently 24.9).
Please ignore everything below; /. wouldn't let me comment without it

The log file is expected to reside in the /var/run directory, which may not be writable very early in the boot sequence, and which is erased a little later in the boot sequence. We therefore avoid writing to the file until we believe it's safe to do so. We also assume that it's reasonable to always append to the file, never truncating it. Optional argument $1 may be "OK" to report that writing to the log file is expected to be safe from now on, or "FORCE" to force writing to the log file even if it may be unsafe. Returns a non-zero status if messages could not be written to the file. rc_postprocess Post-process the output from the rc_real_work() function. For each line of input, we have to decide whether to print t

"What I want is quite simple. To be able to configure and manage stuff with the least hassle."

Then you want systemd. As I mentioned before, the sysvinit start scripts are huge, complicated and error prone (the loop in Apache init script). In systemd all you have is a 17 lines file for Nginx: https://projects.archlinux.org...

systemd adds a lot of extras, and does not take anything away. It adds, a) info on whether the service was started, b) automatic restart of crashed services, c) journald, d) limit resource usage per service, e) simple and powerful service configuration files, f) inter service dependencies management (start Thin only if Nginx is started, or start MySQL after Apache) g) a lot of tools that were missing like systemd-ask-password.

And systemd does not take anything away from you. You can still use all your old school tools and your old style logging, and even the old sysvinit scripts.

"but no standard tool will help you when some opaque software is capturing the initialization process."

I don't know what you mean by that.

"Do you know which flags are passed to eg. your nginx setup? A quick look at the rc.d script will enighten you."

Same with systemd service files, see my example above.

"Is there a bug on the script (it happens more often than you seem to think)? Easy to fix."

In a 9000 bytes script file? You gotta be kidding me. The systemd file is just 17 lines long. The systemd developers have automated tests to make sure their software runs, if you don't trust them, why do you trust the kernel devs or the devs of the services you are using?

"but if not, why the f*ck is it taking control over MySQL initialization? "

What do you mean by that? It starts the service and watches the service that it is really started, and it gives you info that it is started or it didn't started or it crashed. For example, on my laptop:

# systemctl status maradns-deadwood.service
maradns-deadwood.service - MaraDNS secure Domain Name Server (DNS) recursive resolver
      Loaded: loaded (/usr/lib/systemd/system/maradns-deadwood.service; enabled)
      Active: failed (Result: start-limit) since Sun 2015-04-19 23:49:55 CEST; 4 days ago
          Docs: man:Deadwood(1)
    Process: 1472 ExecStart=/usr/sbin/Deadwood (code=exited, status=1/FAILURE)
  Main PID: 1472 (code=exited, status=1/FAILURE)
      CGroup: /system.slice/maradns-deadwood.service

Apr 19 23:49:55 localhost.localdomain Deadwood[1472]: There is no directory /mnt/homecrypt/var/cache/deadwood
Apr 19 23:49:55 localhost.localdomain Deadwood[1472]: Fatal: chdir() failed
Apr 19 23:49:55 localhost.localdomain systemd[1]: maradns-deadwood.service: main process exited, code=exited,...LURE
Hint: Some lines were ellipsized, use -l to show in full.

And yes, it is awesome I use it on my home computers and the development workstation at work.

That sounds miserable. You might try getting a driver/configuration.

I run Arch as well, and like it very much - but at the same time I do realize it is not for everyone, and am not smug about it. Furthermore, you are doing it wrong. You should be using ABS. Instead of step 1. type "abs extra/firefox" (or just "abs", if you wish to get the PKGBUILDs for every package in every standard repo - why you should want to do that, I have no idea, but the option is there). Then "cd /var/abs/extra/firefox". Then proceed to steps two and three. And remove step 3b, that's just lame.

Technically, this is correct.

However, I've tried to make my own custom builds of Firefox and it's a nightmare. The build process used by Firefox is so complicated and convoluted, it would make Rube Goldberg laugh. I haven't tried building Chrome, but reading the build instructions, it appears to be only marginally better.

https://projects.archlinux.org...

1. Download

2. Run "makepkg"

3. pacman -U *.pkg

3b. If you see "No command found" or "Windows cannot find ....", www.archlinux.org

The hardware has changed in some way. There are numerous discussions on the patches required to deal with the changes. There is also an arch thread that covers it and links to all of the pertinent details:

https://bbs.archlinux.org/view...

Why the fuck do you want to round a *sound mixer* inside your *kernel space* ?! Do you run your video decoder and webbrowser there too ?

Because musicians also use computers, and latency -- which is higher if you're going through user space -- is a big no-no. While some latency is acceptable, any trained musician will easily hear 5 ms latency if he's recording, especially with voice. Since FIR filters and the hardware audio chain already add latency, there's really no room for the mixer to add much. Pro audio is actually a major application for real-time Linux kernels: https://wiki.archlinux.org/ind... And saying "but only musicians need this" would totally miss the point that almost everyone starts as hobbyists and amateurs, and the capability should be there already, especially because it's not a big problem to have it -- in-kernel mixing has been available for a long time and works fine.

Sure! In fact, systemd's "nspawn" feature can turn your laptop into a compute cluster of many VMs (if you download enough ram, which, no doubt, is also a systemd feature).

Well all was well running Archlinux with the 3.17.x series of kernels, and then 3.18.x came out earlier this week. Needless to say there have been numerous reports of people who have broadcom wireless adapters saying their networking stopped working because of a kernel panic (o.O)

There is a thread over at arch forums where people are describing various broadcom wireless adapters that stopped working, https://bbs.archlinux.org/view...

So how does this relate to running Linux on a Mac, well most all modern Macs are running some form of broadcom wireless adapter.

In addition to which, you replace it with something that requires more typing, and does not give any feedback. service nfs restart stopping nfsd starting nfsd etc.

systemctl restart nfs

Here you go; put this in your .bashrc:

service() { systemctl $2 $1; }

And the entire concept of *BINARY* logfiles,

Install a syslog daemon and put this in your /etc/systemd/journald.conf?

[Journal] ForwardToSyslog=yes

Or just install syslog-ng 3.6.1+, which requires no additional journald configuration?

xml configuration files [are] insanely stupid when X won't run, or isn't installed (like on a server).

Where does systemd use XML configuration files? (And what does XML and X have to do with eachother?)

And telling me that oh, it boots up *so* much faster means something *only* if I'm on a laptop.

Or a virtual machine, or a container...

KDE on wayland is not complete yet. There has been work for kwin, but one thing is sure: if you want to use it on wayland, you will need, as usual, systemd. Of course, the author points out that this does not imply you will also need to install a web server and a ntp daemon, and that the dependency is on the API not on the program itself, but then show me an alternative implementation i can use. You know, systemd brings nice new APIs and so on, but then I read about the next thing systemd broke. Its in the man page of the shutdown command that this should work.

Arch Linux and a few tweaks and you're good to go https://wiki.archlinux.org/ind...

I'm not sure if there if Angstrom ships with a better network manager, but Arch Linux Arm on the Beaglebone uses the netctl by default, which makes this process quite simple. Just copy and edit the ethernet-static config and systemctl start netctl@enp2s0.

CONNECTION='ethernet'
INTERFACE='enp2s0'
IP='static'
ADDR='192.168.0.200'
GATEWAY='192.168.0.1'
DNS=('192.168.0.1')

You probably won't try it again, but there is a Pacman Rosetta that makes it easy to find the command that does what you want if you know at least one of pacman, yum, apt-get, zypper or emerge.

*breaking news* everything on a computer is binary.
As if there is any difference to use journald or grep or emacs to read the log. journald can even be statically linked without systemd, so that it can be put in BusyBox.
In addition, journald can put advanced features in the log, like signing, crypt, etc, and it have nice user interface, like journalctl --since "20 min ago"
And finally, you still can use syslog or rsyslog with journald.

Compatibility with a classic syslog implementation can be provided by letting systemd forward all messages via the socket /run/systemd/journal/syslog. To make the syslog daemon work with the journal, it has to bind to this socket instead of /dev/log

https://wiki.archlinux.org/ind...

Fine, I though we are talking of a commercial product (" 3. material created or produced and viewed in terms of potential sales"). So, how exactly is Red Hat benefiting by giving away a free init system that their direct competition can use? As for example SUSE Linux GmbH, Mandriva or Debian.

I found this when I was researching "OMG!#! systemd even includes QR code library." Why would they do that? They are smart guys after all, they don't do things without purpose. Then I found this gem. It is actually used to ensure the system is intact and no one has tampered with logs, etc:

http://www.h-online.com/open/n...

It's called Forward Secure Sealing: http://lwn.net/Articles/512895...

Another small gem is "Why, oh why, they created NTP clone?" There is a very good rationale for that, like having coherent timestamps on embedded device boot:

https://wiki.archlinux.org/ind...

Naturally these are optional, and not forced upon you.

There's a nice post over at the Arch forums that breaks it down.

There's a nice post over at the Arch forums that breaks it down.

Why are binary log files such a big issue? First, Linux already is using binary log files in wtmp, secondly, you can still use text log files in systemd, and third, you can see binary log files just as well as text files. Because there is actually no difference between binary files and text files.

https://wiki.archlinux.org/ind...

# journalctl -b | grep NetworkManager

Versus:

grep /var/log/messages

Which one requires fewer commands? For that matter, which one types faster? The one with a long command name and an option flag, or the one with a short command and auto-complete via tabs for the path name. The one that requires a text dump or the one that's ALREADY a text dump? It's not like I need the extra disk space, after all.

I do a log of log following. It adds up.

Besides, the journal on my Fedora box also doesn't seem to rotate out weekly like the logfile did, so that a text dump gives me everything since the day I "upgraded" to a journalctl Fedora.

Why are binary log files such a big issue? First, Linux already is using binary log files in wtmp, secondly, you can still use text log files in systemd, and third, you can see binary log files just as well as text files. Because there is actually no difference between binary files and text files.

https://wiki.archlinux.org/ind...

# journalctl -b | grep NetworkManager

have a read of this section from this article for Arch for a possible solution https://wiki.archlinux.org/ind...

Journald in conjunction with syslog
Compatibility with a classic syslog implementation can be provided by letting systemd forward all messages via the socket /run/systemd/journal/syslog. To make the syslog daemon work with the journal, it has to bind to this socket instead of /dev/log (official announcement). The syslog-ng package in the repositories automatically provides the necessary configuration.
As of systemd 216 the default journald.conf for forwarding to the socket is no. This means you will need to set the option ForwardToSyslog=yes in /etc/systemd/journald.conf to actually use syslog-ng with journald. See Syslog-ng#Overview for details.
If you use rsyslog instead, it is not necessary to change the option because rsyslog pulls the messages from the journal by itself.

Trinity Desktop Environment isn't dead: when I wrote this the last git update was 5 minutes ago (https://git.trinitydesktop.org/cgit/). It's just very very niche, so don't expect much help from your distro.

It's probably easiest to try out on Arch Linux: https://wiki.archlinux.org/ind...

Arch, good guess. You're obviously using something debian based, probably Ubuntu. I haven't used Ubuntu in some years, but I don't remember them actively supporting the use of a ports-like system. It would certainly be possible in Ubuntu, but without community involvement, rather pointless.

Give Arch a try in a VM. I've yet to encounter a piece of software that hasn't had the source converted to a make package by someone in the AUR. Using the AUR is as simple as downloading the tarball, extracting, running makepkg, resolving dependencies, then pacman -S .

Oh, and don't use the base arch installer unless you have a lot of time on your hands. Go with something like ArchBang.

https://bbs.archlinux.org/view...

That's from Arch, but it also uses Systemd and according to that thread you can still get it to work. Not sure if that also works on Debian though.

So what of Lennart calls it "Core OS"? John Romero said he was going to make you his bitch. It's hype/marketing talk. So what if it does replace a far amount of user space on distros that use it? That doesn't prove that systemd will replace the kernel. Furthermore, the time to complain about kernel functionality being moved into user space was when DBus and udev were new. In the meantime, I find that Arch Linux forum post does a good job of explaining systemd's merits.

You can install syslog on a system that uses systemd if you really want text logs. I'm not familiar with journald myself but I've heard there are 'follow' commands for the log file. https://wiki.archlinux.org/ind...

Wikipedia has very detailed information on Intel processors. This page does not list TSX for your processor and does list it for others.

Most Linux distros automatically handle Intel microcode patches (which I assume is how this errata will be handled). See Debian wiki or Arch wiki for details.

I use one of these. Open source comaptibility doesn't get any better than x86_64. Couple with an msata ssd and an Intel AC7260 mPCIe 802.11ac card and the specs beat the hell out of any consumer router. You can use linux or FreeBSD and configure it yourself (I use Arch), or use pfsense for a more dedicated firewall solution.

That depends. The kernel hasn't been moved into Arch's [core] repository yet, but it is in the [testing] one (it was there first, but just barely, according to the times it was just two hours ahead of Gentoo[1] [2]). Not that it matters which was first anyway, they're both rolling release and will have it much earlier than a distro using a standard release model.

[1] ArchLinux testing/linux package push date at 2014-08-04 06:24:21 (GMT) Source
[2] Gentoo sys-kernel/linux-headers changelog change date at Mon Aug 4 09:39:49 2014 UTC Source

The wiki for Archlinux is pretty much the best source of information on the web for linux, as far as I'm concerned. It's valuable even if you're not running Archlinux, with detailed guides for configuration of many FOSS programs.