Slashdot Mirror

None of that speaks to why systemd needs to suck in everything under the sun that has a server mode (like the gimp and open office examples above).

It doesn't.
That a particular distro/package maintainer utilizes their distro's init-system and service manager for launching a daemon is hardly a problem or even controversial.

And just because something's launched often doesn't mean it has to be sucked into systemd. Angry Birds is launched on Linux more often than most stuff the systemd guys play with -- but that doesn't mean all games need insane dependancies on an init system.

It seems to me that have some problems with understanding what an init-system does. SysVinit/systemd/SMF deals with starting daemons and similar processes, not end user programs like games. Of course, if a game has a server mode what uses sockets and what not, then it probably is convenient to use a proper init-system.

Your container example seems to be taking the wrong approach too.

Lightweight containers like Docker seem to suggest it's best to run a single service within a container --- so the last thing such a system needs an init system -- let alone the most bloated init system in the world. A it turns out, it's quite a pain in the neck to run systemd in a docker container.

There are many different OS container modes, from running single services, to full blown servers. Each mode has it advantages and disadvantages. That flexibility is exactly what makes OS containers interesting.

Unlike other OS container implementations, systemd also support running unmodified Linux distros as containers. That means that I can boot a standard Debian distro on top of my Fedora distro, or running a newer unstable version of my distro on top. It takes seconds or minutes (depending on net speed) to launch such a container. A great way to test and debug new stuff without bothering with a full VM.
The "machine concept" that allows maintaining OS containers from the "outside" is also way cool.

All in all, systemd is on its way to become the best OS container manager the world have ever seen, and that is great news for Linux.

And just because something's launched often doesn't mean it has to be sucked into systemd. Angry Birds is launched on Linux more often than most stuff the systemd guys play with -- but that doesn't mean all games need insane dependancies on an init system.

Your container example seems to be taking the wrong approach too.

Lightweight containers like Docker seem to suggest it's best to run a single service within a container --- so the last thing such a system needs an init system -- let alone the most bloated init system in the world. A it turns out, it's quite a pain in the neck to run systemd in a docker container.

Why more So-Ho routers don't implement at least partial BCP38 by default has always baffled me

SoHo routers are using the cheapest, easiest to deploy software possible. They don't care if that means handing out 9 year old software bugs in millions of units. The only way I see BCP38 gaining traction in that market is if it just works out of the box in Linux, with minimal configuration involved. Then the SoHo vendors who just grab Linux derived routing software will gain that capability. If that catches on to where it becomes feature checkbox material--"our new router protects against DDOS attacks with BCP38!"--then maybe we'll get a beneficial arms race.

In the part of Linux land I spend most of my time in, I know RHEL6 starting making basic protection enabled by default. The small Linux distributions router vendors build against lag pretty badly against distributions like that though.

Read Before you initiate a “docker pull”. Note that it contains warnings about almost everything supposedly discovered by this researcher, and it came out before it. That's why no one in Docker land is even taking this seriously. People who are surprised by this aren't aware of what's going on with Docker by definition, because if they were they'd know this is old news.

Docker 1.X is a first release with lots of known limitations--this is one of them--plus the inevitable security issues of any new software. No one with any sense is putting it into production yet.

A report has been released detailing an issue that the reporter is naming "Grinch". This report incorrectly classifies expected behavior as a security issue.

https://en.wikipedia.org/wiki/... and earlier standards are indeed in English. And compilers like gcc, clang, Microsoft Visual C++, etc help flesh out the details.... However the standard defines some things as "undefined behavior" or "compiler-specific behaviour" .. and sometimes changing a compiler to do different or better optimazations can lead some programs to break.

http://developerblog.redhat.co...
There are ways to minimize these corner cases.

http://linux.slashdot.org/stor...
and then there are bugs... and there are always bugs... so sometimes the English spec is more important than the specific results of various compilers...

Also the large collection of c programs helps define the language, just as much as any specific compiler... If a compiler turns on a optimazation that the English spec says should be OK, but it breaks real world programs, then it's not going to fly very well... unless it gets it's own flag perhaps.

Lot's of c compilers are written in c or c++, so they often fall into two categories that help define the language.

http://www.redhat.com/en/servi...

The skills you assert aren't tested for. Most Linux admins I know don't know networking at all. For RHCE, you need to know how to put in settings in a server. But not what they do or what they mean. The Cisco device isn't well understood. The last RHCE I dealt with configured a duplex mismatch and blamed the Cisco for doing what he told it to do. The Cisco device is simple and understood by people who know basics of networking. But RHCEs don't need to know to pass the test, and in practice, don't know.

Why, are you an RHCE? You sound pretty aggressively defensive.

If you search for 887006 or "no IRQ handler for vector" at Red Hat you'll come across a reference in RHEL 6.5 release notes that has decent enough information, including the fact that this was a hardware error: https://access.redhat.com/docu... The "fix" was just to add a log message telling users that their BIOS needed updating when necessary.

Yes, so what init system and service management are they going to use?
Is it meant just for servers? Then they could get away with sysvinit.

If this Debian derivative is meant for desktops too, then you want some type of the systemd solutions to service management, to dynamically change hostname, datetime, do hibernation, add/remove bluetooth/modem devices, multi-seat login, etc...

I think the options are: Upstart or OpenRC; the others are too obscure or untested.
Probably you would have to use the abandoned Consolekit to replace logind?

If you are unfamiliar, this is what (systemd-)logind does (and previously ConsoleKit did part of it):

.
        keeping track of users and sessions, their processes and their idle states,
        creating control groups for user processes,
        providing PolicyKit-based access for users to operations such as system shutdown or sleep,
        implementing a shutdown/sleep inhibition logic for applications,
        handling of power/sleep hardware keys,
        multi-seat management, session switch management, and device access management for users,
        automatic spawning of text logins (gettys) on virtual terminal (console) activation and user runtime directory management.

from https://access.redhat.com/docu...

But this is just life. Heck a Red Hat engineer's already pointed out the fallacy of believing Linux is really about choice: http://www.redhat.com/archives...

That's not to say there's no choice at all in using Linux - heck with systemd there will still be the ability to exhibit control over the system in greater ways compared to most other systems. But the only way for Linux to get out of its rut (and yes, unless you think it should stay as a 1% niche to only be accessibly by geeks and techheads it really is still stuck in a rut) it needs at least SOME standardization in important areas like a broken init system.

This is just how things are. Idealism only gets you so far - sometimes things happen that you have no control over and really the best option is to just go with the flow. FreeBSD has far less capability for desktop use and you give up far more by moving to it than just staying on Linux, accepting systemd as a small part of daily life, and learning how to use it properly. To be completely honest, you might be letting your emotions control you rather than logic. Not all battles can or need to be won.

I continue to hear this and see absolutely no evidence of it. I see evidence to the contrary, in the US, India and Europe, over the last 20 years. Generally, it's RPM/RH that is first listed. It's not alphabetical. This isn't because they are lucky. The simple explanation is that RH is the most frequently used and therefore put at the top as a simple matter of UI layout (most common choices go to the top of a list, within reason).

Here: http://investors.redhat.com/re...
You can also see the report from CA, where they make more in a quarter than a full year of RH: http://www.ca.com/us/news/pres...

This is a fun game, pick me a list that shows more Debian love!

If you rank popularity from the links of the packages, you provably are missing something. I'm a FreeBSD/OpenBSD user, some of the development of Nginx was done in FreeBSD, and you don't even see packages for it in your list. See the flaw in your methodology?

that really is the problem for an application attempting to cleanly shut down the system

systemd's inability to cope with dependency resolution for network filesystems has been a bug for over a year: https://bugzilla.redhat.com/sh...

It really is a problem for an init system attempting to cleanly startup and shutdown a system when it feels the need to mount network filesystems before turning on the network or to turn off the network before unmounting them. (Or turning wired networks off at all, ever.)

Background: I've professionally administered Unix and Linux machines for >25 years, including various BSDs, Linuxes, Irix, HP-UX, Solaris/SunOS, AIX, etc. I've been certified by several vendors or distributions, including, since 1999, Red Hat (which gives me quite a bit of background on their specific implementations over the years). I don't work for a company doing development of any OS or platform. heck, other than random 401K type aggregate ownership, I don't own stock in any company that cares about this issue at a deep level, to the best of my knowledge :)

Personal Bias about this thread: You pretty much lose all the credibility possible with me when you start of with "I ... dislike systemd because ... it looks ... like a poorly-described, gigantic mess I know nothing about ... ." (It's the "disliking something you know nothing about" that bugs me). Otherwise, I don't care much about this debate on a personal level. I currently admin boxes using systemd as well as everything else, and nothing about systemd has caused me anywhere near the heartache that it seems people who haven't used it much seem to feel about it.

Seriously, there're thousands of pages of documentation about what it is, how it works, and what most if not all of the design basis decisions are/were. I'll link you to a few of them because hey, you can get to slashdot and post, but you can't seem to use Google ;) (tongue in cheeck, of course). There're plenty of folks who DO have great detailed reasons on why they don't like bits and pieces of it, and you should be able to compare them to the various info I'm linking below.

Systemd has tons of upside and tons of downside. Most are pretty well detailed, although many of the gut reactions people seem to have to it are based on a lack of understanding about how it works and what it's compatible with, to wit "I can't use shell scripts for anything at startup anymore!" , "All of my old chkconfig or SysV scripts can't be included at all!", "It kills off syslog!", "The only reason it exists is to make laptops boot faster and in the server world we don't care", etc. Those are easily researched and the actual basis (or lack thereof) pretty easily found.

So, for why the systemd setup looks like it does, you can go back 4.5 years to where the announcement and rationale is described. Speed is part of it, as is device changability, as is double-forking, resource limits, and service state checking and recovery. Yes, it's a load of stuff. Definitely a system-wide approach VS a semi-random collection of various ways to do things all tacked together (which is, frankly, what most Unix and Unixlike systems are, through survival of the fittest).

http://0pointer.de/blog/projec...
http://0pointer.de/blog/projec...
http://0pointer.de/blog/projec...
http://0pointer.de/blog/projec...
http://0pointer.de/blog/projec...

Since RedHat's obviously the largest major proponent and arguably the source of the most production users, here's their documentation:

https://access.redhat.com/docu...

Here's the project page with loads of links about the software and uses cases:

http://www.freedesktop.org/wik...

And of course so many questions have been raised the developers have posted their rebuttals to myths or misunderstandings.

http:/

Using the information gleaned from this year old bug I was able to create a Tower of Hanoi solver using the dependency resolver's attempts to determine whether a NFS filesystem should be mounted after the network comes up or not. Every attempt to start Apache (which depended on the filesystem) represents moving a disc to the middle tower.

wasn't this addressed in February?
https://www.redhat.com/archive...

wget prior to 1.16 allows for a web server to write arbitrary files on the client side.

A Metasploit module is available for testing:

https://github.com/rapid7/meta...

the disclosure is here:

https://community.rapid7.com/c...

Redhat's bug is here:

https://bugzilla.redhat.com/sh...

So a port to ARM could be forseeable, with or without Oracle's involvement.

Who told you that?

https://bugzilla.redhat.com/sh...

It looks like the current workaround (8/2014) is to change network filesystems from mounting at boot to automounting on access.

https://access.redhat.com/docu... is a rather comprehensive and good guide to the changes in RHEL 7 for RHEL sysadmins. One thing you'll learn from it is that RHEL 7 logs to text via rsyslog (as a journald consumer) *by default*.

"Oh hey, just what I wanted BINARY LOGS THAT BREAK ALL MY EXISTING AUTOMATION."

systemd is designed to make it trivially simple to have text logs if you want that. RHEL 7 is configured by default to do permanent logging in plain text format via rsyslog; the native journald logs aren't even permanently stored by default (this is the config that was in Fedora for a while before journald's native format became the default/primary).

https://access.redhat.com/docu...

I am starting to suspect you're a troll and haven't actually used RHEL 7 at all.

Rename /bin/bash to /bin/bash.bak then create a link from /bin/dash to /bin/bash ..

Why on earth do you want to do that? If you are running a Rehat distribution on a production machine that is a great way to get fired unless you have the appropriate change requests filled out and even then you would have to install dash which adds an extra level of complexity.

On Fedora 20 as per two days ago:

> env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
this is a test

This is with "bash-4.2.48-2.fc20.x86_64" which does not require a reboot, although if you are like me the latest updates did contain a kernel update as well which does require a reboot.

So at least the latest release of Fedora is patched. As is Redhat 4 thorough 7 see here.

Redhat has patched the bug right down to RHEL 4, which has bash 3.0 which is even lower than Apple's bash version:

https://access.redhat.com/arti...

Since it's GPL I suppose Redhat has already released the source code for their GPL-2 bash versions at the same time as the installable binary updates?

According to Redhat, mod_python/php/etc are not vulnerable.

CGI scripts are likely affected by this issue: when a CGI script is run by the web server, it uses environment variables to pass data to the script. These environment variables can be controlled by the attacker. If the CGI script calls Bash, the script could execute arbitrary code as the httpd user. mod_php, mod_perl, and mod_python do not use environment variables and we believe they are not affected.

This means the overwhelming majority of php installations won't be affected.

At least for RedHat/CentOS, CVE-2014-7169 has been patched now as well. https://rhn.redhat.com/errata/...

At least for RedHat/CentOS, CVE-2014-7169 has been patched now as well. https://rhn.redhat.com/errata/...

At least for RedHat/CentOS, CVE-2014-7169 has been patched now as well. https://rhn.redhat.com/errata/...

But if they are patching xen and xen supports live migration on at least some hosts (At least RHEL can).... Kind of makes you wonder what's the problem.

In forums and bug reports people have asked how to suspend and are always told that the preferred way is to close the lid. See: https://bugzilla.redhat.com/sh... for one example. But GNOME developers have said the primary target is laptops so I guess I should be surprised.

Not fixed https://access.redhat.com/arti...

I'm sorry, I've meant to link to http://seclists.org/oss-sec/20... (you may want to walk the thread up a bit) and https://bugzilla.redhat.com/sh...

Example attacks are listed on Red Hat's security blog.

Take a look at Red hat's CygWin. http://www.redhat.com/services...

It's the 'pre-installed' part that's key. There are lots of times when I sit down at a Windows machine, and I either don't have the owner's permission to install stuff, or even if I do it's going to take 30 minutes just to get everything installed, before I can even start working on the actual problems at hand.

Take a look at Red hat's CygWin. http://www.redhat.com/services...

Unfortunately, Mukt completely mis-reported this and Slashdot picked up their errors for the summary, which is making for a lot of confusion.

tl;dr:

1. blivet-gui isn't supposed to (and in fact cannot) 'replace' gparted in any reasonable sense of that term.
2. blivet-gui is a new application, but its backend is the Fedora installer's storage management code, which is a very old codebase. There is no new storage management backend being written here.
3. Lennart and systemd have nothing at all to do with this.
4. It wouldn't really be practical to 'contribute' this to gparted, as it would involve completely ripping and replacing gparted's backend and then very rapidly proposing significant changes to the GUI, and hence would be a project takeover by any other name.
5. blivet uses standard underlying tools for performing operations, it's just a logic/configuration layer for them.

1: what the original announcement says is that blivet-gui uses a gparted-like UI to make it instantly familiar for gparted users. It doesn't say anything at all about it 'replacing' gparted. That's a pure invention (likely based on a misunderstanding) in the Mukt article. See the original announcement at https://lists.fedoraproject.or... to verify this, if you like. There's no sense in which blivet-gui really *could* "replace" gparted, if you think about it. gparted is an independent project; Red Hat doesn't own or maintain it, so Red Hat can't stop it existing or being maintained. gparted isn't a significant component for either RHEL or Fedora: it's just a leaf package, an app like any other. It's not like anaconda uses gparted as its partitioning tool, or anything like that. So talking about blivet-gui 'replacing' gparted doesn't make any sense, not upstream, not downstream. So long as upstream gparted devs see a need to keep developing gparted, gparted will continue to exist upstream, and so long as a Fedora packager wants gparted to be in Fedora, it'll be in Fedora, whether or not blivet-gui or any *other* storage management GUI app is also in Fedora. We have lots of space in the repos.

2: the backend for blivet-gui is blivet: https://git.fedorahosted.org/g... (packaged in Fedora as python-blivet). This codebase is simply the storage management backend of anaconda (the Fedora installer) split out into its own repository. The split happened back in 2012: http://www.redhat.com/archives... . The intent was to allow for exactly this kind of code re-use. So there really isn't some kind of new NIH effort going on here: the storage management code is not new, all that's new is the light wrapper around blivet to produce a standalone GUI app rather than using it as a part of the anaconda installer. The underlying codebase has existed basically as long as anaconda has existed, which is rather longer than gparted has existed. anaconda dates back to 1999 (https://fedoraproject.org/wiki/History_of_Red_Hat_Linux ), gparted AFAICT dates back to 2004 (http://gparted.org/news.php?item=180 ).

3: Doesn't really need expanding on, but no, there is absolutely zero link to Lennart, systemd, or any other systemd developers.

4: so the reason to do blivet-gui at all, and the reason anaconda doesn't just call gparted for "partitioning" like ubiquity does, is it doesn't cover anywhere near the functionality we actually need for the Fedora (and, more to the point, RHEL) installer. gparted really is a *partitioning* tool, and there's a reason I keep referring to blivet as "storage management". It handles things that aren't just partitions. The most obvious examples are mdraid, LVM, and btrfs (insofar as btrfs acts as a volume management and redundancy system, not just as a simple filesystem like ext), but blivet has all sorts of other interesting capabilities too, primarily of interest t

I'm completely fine seeing things move away from the older "GUI driving non-interactive commands in the background" model, to GUIs and CLIs that are built on shared libraries, because that potentially gives us THREE usable interfaces. However, is it normal for a CLI to lag behind the GUI now in Linuxland?

I see that blivet comes from Anaconda, so I expect some integration there.
It seems like a good CLI could be used to avoid the awkward practice of writing out a kickstart partition fragment from the pre section. We could just drive Anaconda's partitioning directly from %pre with shell logic instead of pooping out Anaconda-ese to be parsed later.

So where's my damned anaconda partitioning CLI already, this would affect more [important] people than yet another partition GUI!!

https://www.redhat.com/en/abou...

"Before Red Hat, Cormier served as senior vice president of research and development at BindView"

-

"BindView started out as "The LAN Support Group" (LSG) and was a developer of a bindery viewer product for the Novell platform called BindView. In 1995, the company changed names from The LAN Support Group to BindView and developed into a supplier of Novell and Microsoft Windows directory administration, vulnerability management and policy assessment & management software - providing customers with the tools to assess, discover and remediate network, hardware or application anomalies."

https://en.wikipedia.org/wiki/...

Obviously. Any other ties to Microsoft?

Looks like the article I linked is out of date ("As of October 1, 2013, MySQL 5.5 packages have been added to the Red Hat Enterprise Linux 5.10 Beta, and therefore will be in the forthcoming GA release."). 5.10 was released on 2013-10-01 according to https://access.redhat.com/articles/3078#RHEL5

Thanks for pointing it out. I've commented on the article requesting it be updated.

Really?

"Red Hat will not issue any more security advisories for the MySQL 5.0 packages (mysql-5.0.* and related packages). Security advisories will be provided only for MySQL 5.5."
https://access.redhat.com/docu...

You mean MySQL 5.0. Latest version via yum on RHEL 5 series is MySQL 5.0.95.

You can backport and install 5.5 on it I believe, but that's not exactly out of the box. This article states that official 5.5 support for RHEL5 is beta...

https://access.redhat.com/solutions/106493

More than a decade ago, when they abandoned desktop and regular users and only focused on enterprise, they made their biggest mistake.

Then you'll be happy to learn that Red Hat is once again selling a Desktop: *Red Hat Enterprise Desktop and Red Hat Enterprise Workstation now based on RHEL 7! It is listed here Red Hat Enterprise Linux

*Disclaimer: I do not work for or am anyway associated with Red Hat, I just use their products along with Fedora

Every one of these is supported by Red Hat. Call them out for other things, but do your research first. I'm upgrading MySQL from 5.1 to 5.5 and many of these are specifically in new Red Hat Collections.
https://access.redhat.com/documentation/en-US/Red_Hat_Software_Collections/1/html-single/1.1_Release_Notes/index.html#sect-Installation_and_Usage-Install

You can already ask some compilers to do what you are asking - it's just often not on in shipped builds.

At compilation time warnings can be generated for out of bounds accesses that can be determined statically. Clang has -fsanitize=bounds, GCC has -Warray-bounds.

As an Anonymous Coward pointed out, it can be hard to detect runtime allocations overruns at compilation time. For these something like Clang's AddressSanitizer (GCC has added it too will help but at a cost of both time (slow down factor of 2) and space which is why you're unlikely to find it enabled on your precompiled SSH server binary. It's true there are cheaper checks (such as GCC's FORTIFY_SOURCE) that are less thorough/specialized that are often enabled by distros.

Never mind trivial things like systemd - the real watershed moment for Old Unix vs New Linux was back in 2011, when a humourless package maintainer excluded 'ddate' from the default build of util-linux:

http://en.wikipedia.org/wiki/D...

https://git.kernel.org/cgit/ut...

https://bugzilla.redhat.com/sh...

Oh, so you're saying Apple's upgrade prices, which range from free to $30, are more than the $1,299 / year that Red Hat charges?
https://www.redhat.com/wapps/s...

Please return to first grade.

No better time to dump on a project than when it receives an award of academic recognition, lol: http://rhelblog.redhat.com/201...

Source: http://investors.redhat.com/fa... Disclaimer: I work there.

As of this posting it doesn't look like Scientific Linux has released an EL7 version yet.
Given the announcement earlier this year about greater collaboration between Red Hat and CentOS communities you'll most likely see more up to date releases and errata from CentOS than Scientific Linux I would imagine:

http://www.redhat.com/about/ne...

Red Hat Enterprise Linux 7 beta supports 40G Ethernet link speeds, which enables faster network communication for systems and applications.

What was the max supported link speed previously in RHEL 6...10G?

I was going to the FTP site to look at the sources, but apparently they have moved.

Current sources for Red Hat Enterprise Linux 7 have been moved to the following location:

https://git.centos.org/project...

That's a bit cool actually.

Arker: "In this case, because OpenStack is something RedHat is pushing hard .. it might be a reasonable expectation that they would at least be somewhat less than totally rigid about it."

Since when has any Open Source outfit offered 'free' support. The license specifically state that the software is distributed free of charge, not free of support charges ..

Apache License, Version 2.0

"If you are looking for enterprise-level support, or information on partner certification, Red Hat also offers Red Hat Enterprise Linux OpenStack Platform."