Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror

Comment: Re: systemd rules!!! (Score 1) 464

by fisted (#49562871) Attached to: Ubuntu 15.04 Released, First Version To Feature systemd

1) The procedure you mentioned precisely do not use any helper script. This why it take 4 files

...two of which are helper scripts...

, exactly the same amount of file on system V init.

Not quite, but whatever.

2) The /usr/local/bin/net-up.sh and /usr/local/bin/net-down.sh are absolutely not related to systemd at all. You will use exactly the same scripts with system V init if you don't use helper scripts.

...except for those two helper scripts, yes... They are /not/ required in sysvinit. There's nothing to stop you from doing something like that on system V, but the canonical way would be to do that in the init script. So regarless of whether the helper scripts are an unrelated or an integral part of systemd, using systemd in Arch for the highly complex use-case "static IP address" apparently means one way or another, they have to appear. Stop trying to excuse that away.

The fact that this 2 scripts use a configuration file is neither relater to systemd.

Sure, there's nothing wrong with a configuration file. What you're trying to say here, not so sure.

3) Yes this is pointless to compare systemd over system V init by showing an example that is nothing related to systemd.

I don't even know what to reply to this ... odd ... statement. I'll grant you the benefit of the doubt and assume you live in some twisted sort of parallel universe where 'nothing related' means 'entirely related' or so..

4) I also claim to have ton of experience in C. From the distribution maintainers point of view, scripts or C applications are exactly the same problem: when there have to fix something, there need to publish a new package

You're missing the point. I wasn't talking about the point of view of distro maintainers, but the case when you, a sysadmin, first encounter a problem with a script or program. Please, with that in mind, reconsider that part of what i wrote.

, the fact that it require a compilation is a detail, especially given how ubiquitous is a C compiler on a maintainer machine. Well written scripts or C applications must log debug messages to help tracing problems. Now take a look at the reality: there is very few scripts that are well written, mainly because the authors assume that it's easy to read the script. On the contrary many C applications a well written because the authors know that the users will have nothing to show in case of a problem. The 'set -x' is not a magic trick that allow to find any problem a stack of scripts might have. The dependencies problem of the init scripts is one of them.

(I mostly agree with this, but it's beside the point)

5) Because I usually wrote French and in that language we put a whitespace in front of question marks. I did not notice that it's not the same in English.

Fair enough. So a twisted parallel universe it indeed is! (just kidding)

Comment: Re: systemd rules!!! (Score 1) 464

by fisted (#49559241) Attached to: Ubuntu 15.04 Released, First Version To Feature systemd

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?

Comment: Re:Cripple Linux? (Score 1) 174

by fisted (#49550965) Attached to: Intel 'Compute Stick' PC-Over-HDMI Dongle Launched, Tested
I sure did look at it (and it made me laugh *even* harder, but that's beside the point).

I'm sure willing to believe that you "know better than me" how to deploy big monolithic number crunchers "globally for a living". Unfortunately for you, this was about networking. (It's a fairly new idea, you might not have heard of it yet).
So I'd suggest you familiarize yourself with the fundamentals of networking, in order to avoid making yourself look like a complete idiot next time

Comment: Re: systemd rules!!! (Score 1) 464

by fisted (#49550883) Attached to: Ubuntu 15.04 Released, First Version To Feature systemd

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.

Comment: Re: systemd rules!!! (Score 1) 464

by fisted (#49549585) Attached to: Ubuntu 15.04 Released, First Version To Feature systemd
The other day I had a spare machine sitting around, and decided to install some "modern" Linux distro, just to get some first-hand experience with systemd. I decided to install Arch. Halfway through the installation, I arrived at the network interface configuration. I do run a dhcpd, but for this test machine, I decided to set it to a static IP address (in 192.168.1.0/24).
For a first quick reference, this is how you would do it on *BSD (the interface being xyz0):

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 the line to the console, print a twiddle on the console, print a line to the log, or some combination of these. If rc_silent is true, then suppress most output, instead running rc_silent_cmd (typically "twiddle") for each line. 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.

Comment: Re:even when in offline mode (Score 3, Informative) 117

by fisted (#49540581) Attached to: iOS WiFi Bug Allows Remote Reboot of All Devices In Area
Well I kind of chuckled when you said

How did it take you that long to read the handful of comments that existed at the time?

because it couldn't make more clear how (as per /. etiquette, of course, I know) directly jumping to the comment section is your usual MO, when in reality, the occasional guy who actually does spend a few minutes on reading TFA is not unheard of.
Therefore it could have been a funny and subtle troll as well; thanks for ruling out that possibility :).

Besides, It's also very possible that the poster just reads /. the way I do, which is skimming the front page for stories of potential interest (i know, i know), opening them in background tabs, and only /then/ going through the opened stories, eh, comment sections, one by one. So there's quite a delay between clicking on a story (causing comments to be loaded), and actually looking at it for the first time.

At the source of every error which is blamed on the computer you will find at least two human errors, including the error of blaming it on the computer.

Working...