Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror

Slashdot videos: Now with more Slashdot!

  • View

  • Discuss

  • Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

×
User Journal

Journal: What do I have to enable now? Fucking DICE. 5

Journal by drinkypoo

Welp, I can use Slashdot in Chrome and not in Firefox, which implies that something I'm blocking in Firefox is preventing the new improved Slashdot from working. What new spyware bullshit do I have to enable to use Slashdot now? Thanks, DICE! You'll run this place the rest of the way into the ground any day now.

User Journal

Journal: Systemd (or, how to make portable software) 10

Journal by phantomfive

In this post, Lennart explains that he doesn't know how to write portable C code. He says:

[Making systemd portable] would turn every second line of systemd into #ifdefs.

The purpose of my post here is to explain how to write portable code, without #ifdefs on every other line. If that happens, you are doing it the hard way.

An easier way is to create an OS independent layer. Call it OSI (since no one is using that acronym anymore, right?). Create a header file that declares all your functions, then create an implementation file for each platform. Every time you find a piece of functionality that is different on different platforms, throw it into that header file.

For example, if you need to take a screenshot, it will be different on every platform you find. In the header file, create a function OSI_Screenshot(). Then in your OSI_Windows.c file, add an implementation for windows. In your OSI_Linux.c, add a screenshot implementation for Linux. In your OSI_OSX.c, add your implementation for OSX. This technique can also work for extremely incompatible platforms, with OSI_printf(), or OSI_malloc(), etc. If you use your compiler correctly, you can compile it without any extra overhead from the function call.

An example of this technique can be found in Android (look at sysdeps.h and sysdeps_win32.c), demonstrating that this technique works. They don't have #ifdefs scattered throughout their code. The Android example is tougher than it needs to be, because Android added the compatibility layer after the code was written. If they had started at the beginning, the code would have been much simpler.

The lack of knowledge (about how to write portable code) in the systemd team is causing them to make bad decisions, because the alternative seems too hard. For example:

I have no plans porting it to other kernels, and I will not merge any such patches........Quite frankly, I'd like to question [cross-platform compatibility]. In the light of GNOME OS I think we need to ask ourselves the question if we do ourselves any good if we continue to support all kinds of kernels that simply cannot keep up with Linux anymore.

Those who don't understand the failures of the past are destined to repeat them. Plenty of vendors try to focus on a single platform, and their work disappeared, to be replaced by something that was cross-platform compatible, and usually better work. The discipline required to keep things portable results in better code (there's a quote from Mythical Man Month that fits here but I'm too lazy to look it up). The Gnome developers understand the importance of portability but that's a story for another post.

User Journal

Journal: Systemd's solution to large init scripts 1

Journal by phantomfive

(Note: When you write code, you're making a UI for programmers. Learn to do it well.)

Below you can see a traditional unix init script. It's long, but if you're familiar with shell-script you can figure out what is going on. There is a lot of redundancy here, most init scripts have a switch that runs an option based on the first command-line parameter, for example. One solution is to put common code in a function, but Poettering decided to use config files.

Let's examine the general tradeoff between putting code in a function, and using config files (a form of declarative programming). Config files are fine as long as there aren't too many special cases. If there are too many special cases, you end up with so many options and keywords that it would have been easier to just use a scripting language.

The good side is systemd saves a lot of typing. Way down at the bottom, is a unit file for the same init script. It's clearly shorter, and easier to type.

The bad side is it has arcane keywords which are are not discoverable merely by looking at the file. This is a pattern that repeats itself over and over in systemd, things are easier if you know how to do them, but the system itself is inscrutable without arcane knowledge.

Ideal systems fulfill the requirements while making it easy for those who want to dig deeper. The system opens like the petals of a rose.

#!/bin/bash
# Starts the abrt daemon
#
# chkconfig: 35 82 16
# description: Daemon to detect crashing apps
# processname: abrtd
### BEGIN INIT INFO
# Provides: abrt
# Required-Start: $syslog $local_fs
# Required-Stop: $syslog $local_fs
# Default-Stop: 0 1 2 6
# Default-Start: 3 5
# Short-Description: start and stop abrt daemon
# Description: Listen to and dispatch crash events
### END INIT INFO
 
# Source function library.
. /etc/rc.d/init.d/functions
ABRT_BIN="/usr/sbin/abrtd"
LOCK="/var/lock/subsys/abrtd"
OLD_LOCK="/var/lock/subsys/abrt"
RETVAL=0
 
#
# Set these variables if you are behind proxy
#
#export http_proxy=
#export https_proxy=
 
#
# See how we were called.
#
 
check() {
    # Check that we're a privileged user
    [ "`id -u`" = 0 ] || exit 4
 
    # Check if abrt is executable
    test -x $ABRT_BIN || exit 5
}
 
start() {
 
    check
 
    # Check if it is already running
    if [ ! -f $LOCK ] && [ ! -f $OLD_LOCK ]; then
        echo -n $"Starting abrt daemon: "
        daemon $ABRT_BIN
        RETVAL=$?
        [ $RETVAL -eq 0 ] && touch $LOCK
        echo
    fi
    return $RETVAL
}
 
stop() {
 
    check
 
    echo -n $"Stopping abrt daemon: "
    killproc $ABRT_BIN
    RETVAL=$?
    [ $RETVAL -eq 0 ] && rm -f $LOCK
    [ $RETVAL -eq 0 ] && rm -f $OLD_LOCK
    echo
    return $RETVAL
}
 
restart() {
    stop
    start
}
 
reload() {
    restart
}
 
case "$1" in
start)
    start
;;
stop)
    stop
;;
reload)
    reload
;;
force-reload)
    echo "$0: Unimplemented feature."
    RETVAL=3
;;
restart)
    restart
;;
condrestart)
    if [ -f $LOCK ]; then
        restart
    fi
    # update from older version
    if [ -f $OLD_LOCK ]; then
        restart
    fi
;;
status)
    status abrtd
    RETVAL=$?
;;
*)
    echo $"Usage: $0 {start|stop|status|restart|condrestart|reload|force-reload}"
    RETVAL=2
esac
 
exit $RETVAL

-----------------------------------------------------------------------------------------

[Unit]
Description=Daemon to detect crashing apps
After=syslog.target
 
[Service]
ExecStart=/usr/sbin/abrtd
Type=forking
 
[Install]
WantedBy=multi-user.target

Reference to the examples.

User Journal

Journal: systemd - Why did Debian Adopt it? 8

Journal by phantomfive

There's a Debian debate page, but it's disappointing and everything systemd does is listed with equal value. Thanks to Russ Albery for making a much more balanced assessment, explaining what he likes. The short answer to the question is: SystemD makes things much easier for people writing init scripts. It wasn't about cgroups, or speed, or login managers, it was about writing easy init scripts.

Here are the major complaints he has with the traditional startup system:

* Lack of integration with kernel-level events to properly order startup.
* No mechanism for process monitoring and restarting beyond inittab.
* Heavy reliance on shell scripting rather than declarative syntax.
* A fork and exit with PID file model for daemon startup.

He furthermore points out these problems with startup scripts:

The model of fork and exit without clear synchronization points is inherently racy, the boot model encoded into sysvinit doesn't reflect a modern system boot, and maintaining large and complex init scripts as conffiles has been painful for years. Nearly every init script, including the ones in my own packages, have various edge-case bugs or problems because it's very hard to write robust service startup in shell, even with the excellent helper programs and shell libraries that Debian has available.

Those are the main things that systemd fixes for a distro builder, and probably why so many distros have switched to systemd, because it was built for them.

User Journal

Journal: Keep burning those modpoints, punk 4

Journal by drinkypoo

http://slashdot.org/comments.pl?sid=6928647&cid=49008431
http://slashdot.org/comments.pl?sid=6921395&cid=49008481
http://slashdot.org/comments.pl?sid=6928395&cid=49008511
http://slashdot.org/comments.pl?sid=6928647&cid=49008549
http://slashdot.org/comments.pl?sid=6921395&cid=49008565

User Journal

Journal: Yay, I made an idiot angry! 8

Journal by drinkypoo

Then they modded down five of my comments in a row. Why doesn't the system catch this kind of obviously abusive moderation? Oh right, because this is slashdot, not someplace with competent employees.

http://slashdot.org/comments.pl?sid=6897301&cid=48979217
http://slashdot.org/comments.pl?sid=6897699&cid=48979955
http://slashdot.org/comments.pl?sid=6898589&cid=48984949
http://slashdot.org/comments.pl?sid=6904433&cid=48985865
http://slashdot.org/comments.pl?sid=6904445&cid=48986419

If moderation on slashdot were intelligently designed, this person's abusive moderation would have been autodetected and they would have been banned from moderation permanently.

User Journal

Journal: systemd - A descendent of Apple's LaunchD 1

Journal by phantomfive

Systemd is a descendent of Apple's launchd, Lennart suggested the world watch this movie to learn about it, so why? What is good about launchd?

OSX has an excellent inter-processing message system, part of the mach kernel (which they got from CMU). Because of this, many times processes talk to each other through the standard messaging queues. If you use a library to launch a browser window, or query wifi strength, it will communicate through a message queue (although the library takes care of the details).

The interesting thing is that launchd can open a message queue before the recipient is running. So launchd doesn't launch services until they are needed, and if they aren't needed, they never get launched. The benefit is that resources are preserved, things don't get launched until someone sends a message.

The benefit here is dependency resolution. Instead of forcing a deep calculation of what depends on what, or forcing the server script to declare everything it depends on, you can say "manage all these thousand services!" and only the few that are needed will be used, when they are needed.

Another thing I think Lennart copied from launchd is the declarative config files. You don't need to write a shell script, you merely need to indicate what should be launched, and maybe give it configuration options like "relaunch on failure" or "launch completely before receiving message." Of course, some people like config files, others prefer scripts.....that's not an argument I want to get into here, I'm merely pointing out things that seem to have come from launchd. (

What is bad:

Launchd is utterly undiscoverable. It would have been nice of them to put a README in /etc/rc/ or something saying, "hey, all your startup scripts are gone, look elsewhere."

Launchd has a complex hierarchy of directories that it searches for startup scripts. They have justifications for why, and a reason behind each one.......but justifications and reasons are not the same as good design. Every bad design decision ever made had a justification and a reason.

User Journal

Journal: Systemd - Efficiency and Pike's Rules of Programming 4

Journal by phantomfive

(DISCLAIMER: These are my notes and might be wrong.)

Lennart Poettering has never heard of Rob Pike's rules of programming. Let's examine why:

He said, "On my system the scripts in /etc/init.d call grep at least 77 times.... that has to be incredibly slow...., and should be rewritten in C."

You can time it yourself, with this command:

time for i in {1..77}; do grep user /etc/passwd > /dev/null; done

On my machine it takes 0.229 seconds.

Lennart didn't get the speed increase he wanted. From his benchmark report, "booting up with Upstart takes 27s, with systemd we reach 24s." This result isn't too bad: when I've made a similar mistake of writing code before timing anything, ignoring Pike's rules for programming, once I actually slowed the system down.

If you don't measure, you can't optimize.

For entertainment and enlightenment, here is a quote by Ken Thompson talking vaguely about Pike's rules for programming:

Early Unix programmers became good at modularity because they had to be. An OS is one of the most complicated pieces of code around. If it is not well structured, it will fall apart. There were a couple of early failures at building Unix that were scrapped. One can blame the early (structureless) C for this, but basically it was because the OS was too complicated to write. We needed both refinements in tools (like C structures) and good practice in using them (like Rob Pike's rules for programming) before we could tame that complexity.

User Journal

Journal: SystemD: The Beginning 7

Journal by phantomfive

DISCLAIMER: THIS CODE REVIEW IS A LONG WORK IN PROGRESS, I COULD BE COMPLETELY WRONG IN ANYTHING I SAY.

To do a proper code review, you need to understand the purpose of the code, what all the stakeholders want. From my own perspective, init scripts work fine, but since Unix companies keep trying to create new init systems, they must have different needs than I do.

Here's a list of the stakeholders. I need to figure out what their goals are.
1) System admins.
2) Desktop users.
3) Distro builders.
5) Android (if systemd turns out to be good enough).
4) Programmers

My suspicion is that systemd has taken over because it makes things easier for 3.

At its core, Unix is a system for programmers. What other system comes with a compiler and multiple interpreters by default? Bash is so much more useable than DOS, or even powershell (yeah, go ahead and flame me but I'm right, Powershell doesn't even have < working). Unix was designed by programmers and for programmers.

The reason I'm talking about it is the traditional init process is incredibly discoverable. All you have to do is look in the /etc/rc directories, and you can figure out how your system boots. You can see it all. For a programmer it's easy. Poking around in the system to understand it is one thing that makes Unix great (and what I like about Slackware: the whole thing is lovingly crafted).

So that describes the approach I am taking to code review, and to the init process. Hopefully Systemd is an improvement.

User Journal

Journal: Obama's executive order

Journal by pnutjam
I have opinions, but I won't state them here. You can go through my posting history and probably figure it out.

I would ilke to say:
Thank God Obama has given millions of American families something to discuss at Thanksgiving dinner. I'm looking forward to a rousing and intellectually stimulating conversation that will certainly not end in anything good.
User Journal

Journal: Can Capitalism and Democracy Co-Exist? 1

Journal by PopeRatzo

http://www.nakedcapitalism.com/2014/10/can-capitalism-democracy-co-exist.html

I'm going to say that no, finance-driven capitalism like we see in the US and UK cannot exist is inherently anti-democratic. Industrial driven capitalism has a better chance.

User Journal

Journal: Not a Racist Country? Really? 23

Journal by PopeRatzo

A black man is gunned down by police for handling a toy gun in a Walmart. A gun that Walmart was selling.

http://www.vox.com/2014/9/24/6839953/video-john-crawford-walmart-police-beavercreek-ohio-toy-gun

But this white guy can carry a real, loaded rifle (and body armor) in front of a school, refuses to show ID to police and nothing happens.

http://politix.topix.com/story/14304-was-this-man-wrong-to-demonstrate-open-carry-in-front-of-a-high-school

Open Carry laws are clearly meant just for white people. Laws that only apply to one race are the definition of racist.

User Journal

Journal: More Than Enough - Comcast declares war on Tor 31

Journal by PopeRatzo

If you haven't dumped Comcast yet, you better hurry:

http://www.deepdotweb.com/2014/09/13/comcast-declares-war-tor/

Reports have surfaced (Via /r/darknetmarkets and another one submitted to us) that Comcast agents have contacted customers using Tor and instructed them to stop using the browser or risk termination of service. A Comcast agent named Jeremy allegedly called Tor an âoeillegal service.â The Comcast agent told its customer that such activity is against usage policies.
The Comcast agent then repeatedly asked the customer to tell him what sites he was accessing on the Tor browser. The customer refused to answer.
The next day the customer called Comcast and spoke to another agent named Kelly who reiterated that Comcast does not want its customers using Tor. The Comcast agent then allegedly told the customer:

"Users who try to use anonymity, or cover themselves up on the internet, are usually doing things that arenâ(TM)t so-to-speak legal. We have the right to terminate, fine, or suspend your account at anytime due to you violating the rules. Do you have any other questions? Thank you for contacting Comcast, have a great day."

User Journal

Journal: My Public Key data

Journal by VernonNemitz

This post relates to the preceding "Web of Trust" post. I'm putting my Public Key on the Internet in multiple places, where people can access it and see that it is the same data in those different places --and where, presumably, only I had the ability to post that data in all those places. At this writing the data can be compared at this site and this site, and is downloadable from here as a file that can actually be used for things like verifying digital signatures. (You could also open the file with a text editor and compare its data with the data below.)

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1

mQGNBFP0m3QBDAC9ggIDfVLDZWNjqlaF3zsb9yn2kF6ekG5P0a5ZSCcX1KtwEOsQ
RtlVzB2eFi5cGBrNlHO/6kvywo0rogHgUPzQAasLELcMBHALjgF4Gk83PKjdgQGN
e7wqS+0Zux1x0Vgqp7Fg4OHot1FvHtsWkUrNjC0KMlspvNxm5gOh8ohv8weLqaNX
Ewkg0GFTj0OLMTW3vCIApabkTZ23PA4BAdRRtMSKzyXIfwkiVzZwB4BqHnShhD8G
orfXOuc++M4gYH+1c5VYwLrtHTgqwaNkaV/yqa6C+fFA+Dww3PN79oetfc2ugaUT
uV/RBGydyBJQ3o7TT2z92UJ4O5Js9P1XChF8DmwgbxAv52pRVlpwEL1ByB0PQghW
uzjWZmxMfQcW0Uvy4WHeFy2ayN1qgXCXPVw/XuRqIlsKrXAiSp1oYzRci6wKrJ4d
LsUViFcZVN7jMoh+KMuvQ2kGcc37CJe8rEr/dWHPoHANL7V6MKDKlvbTjr9/VA8P
DY8+p/yyQ8gN+l0AEQEAAbQ8VmVybm9uIE5lbWl0eiAoQWZpY2lvbmFkbyBvZiBN
YWQgU2NpZW5jZSkgPHZuZW1pdHpAcGlubi5uZXQ+iQG4BBMBAgAiBQJT9Jt0AhsD
BgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRDGbQ27MGUrEiZNC/9+SQjn8v8t
0iFtl0s7eCrL4wiPuRnLFzhW+JTvMIgtItFlEvVIhY9sKqk6R2liI/vbAwyztfGw
YZZPIJClNT4XL9qhvAIcUVSteflUUVn6fTmKleI7/fiYbYD2ZI0dKsUTGucoiG4Y
xbmE+V2W+OyNZmnMkovQrTb9H16eLOT1PMa0zEDKZ+MfNv2KO0SdMzqZS6RIn7Qu
kosiQR3lh6wmYtoPTg3iX46X30yTQMxxOPrM7JcJdUQX4LdaKLI1ecXNA4jtzs2E
SeBy9alFtpmcjznhrq7P9PXQ+WawgRuyON7Xsvdx+aKmhmZfsO/GdYYD0pGYkYRv
NW3vwY0XHlkKD/pwC4QfFE/TQO0CB8fOH+gajQwUQ5Uk9ztc6m6GFE//quVmGujE
VRTa8wZEpfEX6cI6PXeUqNcJrRFGCBDn0HNce7oUlAacAKn43bF8tfwmevu5JrnT
UKLWnKm2HznB3KmZiQHeGNWIVFdctKqGkvuh9jcARqhpJ8cYZ6YAMWI=
=FZsy
-----END PGP PUBLIC KEY BLOCK-----

User Journal

Journal: Web of Trust

Journal by VernonNemitz

Think about the number of different sites you typically visit, and the number of sites where you joined to become someone who could post some sort of content. You've probably used different passwords at those sites, which means that, in general, you are the only person who is able to access your accounts at all those sites. Now suppose you fired up a "Pretty Good Privacy" program like "GnuPG", and created a Private Key (that you keep secret) and a Public Key that you post at multiple web sites. Since this would be the same data at each site, and it is assumed that only you can access your accounts at all those sites, it logically follows that there is a high probability that no hacker has posted a Public Key while pretending to be you. You have basically used the Internet to create a Web of Trust that authenticates you! Think about that in terms of SSL Certificates and Certificate Authorities --they charge big bucks to verify that you are you, so that the SSL Certificate you get from them can be trusted by others. But instead of that, you could create a "self-signed" certificate, and associate it with a "digital signature", which you also post at multiple web sites. Again, when the same data is at multiple places that only you can modify (and when the data includes a list of those places), it follows that others can trust that your self-signed certificate is practically as good/valid as one issued by a Certificate Authority.

"Life sucks, but it's better than the alternative." -- Peter da Silva

Working...