×

Announcing: Slashdot Deals - Explore geek apps, games, gadgets and more. (what is this?)

Thank you!

We are sorry to see you leave - Beta is different and we value the time you took to try it out. Before you decide to go, please take a look at some value-adds for Beta and learn more about it. Thank you for reading Slashdot, and for making the site better!

Comments

top

Judge Unseals 500+ Stingray Records

Endymion Re:Consent of the Governed (160 comments)

We have no representative government until several things happen:

So time to bring back "No taxation without representation"?

2 days ago
top

Debian Votes Against Mandating Non-systemd Compatibility

Endymion Re:No trust (555 comments)

We've been explaining this for years, only to face the slurs and word-game attacks by the systemd advocates.

Once more unto the breach, dear friends

First, re: monolithic. What IS a factual effor is that, when discuss software, the term "monolithic" has anything at alkl to do with the number of files a project happens tro compile into. To claim that something has a "monolithic design" is to claim that the features are far too thightly coupled, and cannot be replaces individually should the need arise. That need can range form personal opinion, to some horribl security flaw being discovered. Really, this is an extension of the idea of trying to write "modular code" instead of an unmaintainable pile of spaghetti. Systemd is the worse case I've ever seen a project heading down the "spaghetti" route, and maintainabiliity in the future is goign to be painful once the needs of the real world start making demands against the "simple" desing systemd started as. In this sense, it is a repeat of the "hal" fiasco. Only worse., given how much more money and time that has been invested so far.

That's just a general technical critique. The real problem with systemd is not technical, but the fact that it is actively trying to remove the unix nature of linux and replace it with a more windows-ish style. Yes, that is opinion.. Some of us are of the opinion that we came to unix to get a better OS than the hard-to-use, obscure-by-design windows style of OS. So we will never be using systemd, as the very nature of what systemd enforces goes against the very reason we currently chose to use linux in the first place. The only reaon you see anger here is because Lennart choose the wrong way to implement these goals. He could have forked off a ux and made his own sandbox where he is free to do whatever he wants. Instead, he is ripping apart a place others call their home.

There is an evern deeper problem in play here, too. The maintainability is enough of a reason for the sysadmins to fear systemd, and my personal opinion and personal requirements are enough for me to avoido systemd, but those are both local concerns. The bigger problem, which rarely talked about due to the systemd advocates yelling about everything else and idstracting a lot of people with technical minutea is a problem of ideology and Free Software.. As we used to say here on /. many years ago, sometimes the "free as in speech" of Free Softwware is more important than the "free as in beer" ($$$/cost) of Open Soruce. See the the usual sources like the FSF foir why; what matters is some of us choose to release projects under the GPL, for ideological reasons, and not the "Lesser" variant, the "LGPL". This makes it harder to use tsome software in proprietary code., which was the intent behind the choice of the GPL over the LGPL.

Well, that pisses off a lot of people, would would liek to sue Free Softwarein their products (distribution), but not be bound to the GPl's requirements. Which brings us to how systemd is an end-run around the GPL in a new variant on "tivoization". (k)Dbus is simply an excuse to say you're not "linking" to GPL code, by making all API calls into RPC. As someone who has worked on building a community of Free Software, this will be a devistating setback. (stevel explains it in more detail at that link)

Of course, the fact that systemdj's compartmentalization (with cgroups) to create a purposfully opaque box you're not supposed to care about is exactly how you would pull some scheme to force DRM into linux, and I'mm sur ethe NSA just loves having such a huge pile of new, overly complicated, pile of C code placed into such a key position. These are good reasons for avoidin systemd, but like the technical arguments , are not partciularly important.

//Just watch: I"ll be accused of being "supid" or "paranoid" for posting this, yet nobody will refute the main point about how you firce the GP/LGPL distinction to vanish when tall API *mist* be done through (k)dbus. I wonder if JTRIG is paying any of them?

about a week ago
top

Debian Votes Against Mandating Non-systemd Compatibility

Endymion Re:Another Annoying Dependency? (555 comments)

Oh, and I forgot to address this bit:

it does nothing for you unless your app uses ALSA libraries, so it doesn't help your any with your /dev/dsp using app.

So which is it? Lying? or yo've never actually used ALSA and on't know how it worksk?

This is part of the config file I mentioned in my other post, that handles the OSS->dmix routing.

# try this file as your ${HOME}{/.asoundrc
# for the dsp0 sections to work, you will need the OSS compatability
# kernel drivers. IIf you never get a /dev/dsp, try running:
# sudo modprobe snd-pcm-oss snd-mixer-oss
#

pcm.dmixer {
        type asym
        playback.pcm {
                type "dmix"
                slave {
                        channels 2 #assuming 2-ch stereo
                        pcm {
                                type hw
                                  #adjust these to fit yoru hadware
                                card 0
                                device 0
                                format S16_LE
                                rate 44100
                      }
                }
                bindings {
                        0 0
                        1 1
                ]
        }
        capture.pcm "hw:0"
}

# route /dev/dsp to dmix

pcm.dsp0 {
        type plug
        slave.pcm "dmixer"
}

ctl.dsp0 {
          type plug
          slave.pcm "dmixer"
}

# repeat ^^^ as pcm.plug1/ctl.plug1as needed,
# if you have if have more than one sound device.

# set defaul ALSA route to the same dmix
pcm.!default {
        type plug
        slave.pcm "dmixer"
}

ctl.!default {
          type plug
          slave.pcm "dmixer"
}

about a week ago
top

Debian Votes Against Mandating Non-systemd Compatibility

Endymion Re:Another Annoying Dependency? (555 comments)

I don't think you remember how things were before PulseAudio.

No, we remember quite clearly. ALSA worked just fine, with only one easily fixed issue: distros needed to set asourdrc to use dmix by default. Those of us that have multiple soundcards and pre demanding requirements (music pa/production)went through the minor trouble of setting up jackd, which solved all the rest of the problems regarding synchronization and very-low-latency data processing.

Really, the only thing that ALSA needed was a nice GUI editor/frontend for the config file. Those of us that used jackd already had such an editor (qjackctl, among others).

Oh, what's that? You want to claim that PA forced better drivers? That may be true, but it is not a feature of PA, nor a reason to use it. (driver fixes are orthogonal, to which software uses the drver) . Some of us actually read the hardware compatability lists before buying our hardware, too, and never had a problem with stabilitgy.

PA basically handles everything and provides interfaces for everything,

Yes, it is a wrapper around ALSA (unless you someohow usedd some some other type of sound driver than the ALSA snd-card-*.ko kernel modules). It adds latency and a giant pile of useless overengineering, when a simple config file was all that was needed (and maybe GUI editor for that file). Any of the fancier features provides were better served by jackd anyway.

Oh, and that's when it works. Even just a year ago, when I last tried PA, it introduce a shocking number of compatability problems for no good reason, and stilll added a LOT of latency.. I'm not even talking about the non-sound issues!) by simply uninstalling PA so everything fell back to using ALSA by itself. The list is so large now, that even non-technical people I know make jokes about how bad PA is.

As usual, while there is some need for improvement in ALSA ( and other linux features, but the bloated, non-working, latency adding mess called PulaseAudio is *not* the solution.

about a week ago
top

Debate Over Systemd Exposes the Two Factions Tugging At Modern-day Linux

Endymion Re:Not true. There's a different division (863 comments)

Your'e close - the split is indeed between the older Unix types and people that just want to be "users", but you need to recalibrate where their relative positions. Those of us that are against being forced to use[1] systemd see this in a different light. As computers became inexpensive over the last decade, a new generation of younger people joined the Linux community. They were young an inexperience, and often made well-known mistakes in their software. Thats was ok - we were all n00bs at first, and many of us tried to gently nudge the inexperience developeers in useful directions. Very few listened, and have now decided that anything "old" is bad.

Listening to those that came before you is important, if you want to avoid making the same mistakes. A lot of those lessons are collected under what many refer to as the "Unix Philosophy". Mostly, that "philosophy" is jsut a handful of tricks that make maintainance saner. A lot of the stuff that people claim is "overcomplicated", "messy" or an "archaic design" is such an "ugly" state for a reason, and those messy bits are bugfixes. The nice ideal design we all starty with rarely fits exactly when we introduce it to the problems and unforseen circumstances in the real world. That ugly spaghetti-code-style hack that seems to ignore and bypass the "correct" way? That is probably a bug fix, and by removing it you probably reintroduce the bug.

You call us luddites, but heed our warning at your own peril. Some bugs and bad designs have happened before, and a key reason why we don't like systemd is that it makes one of the worst mistakes you can ever make when designing software: it throws out the supposedly "old" or "ugly" parts. I suggest readoing Joel Spolsky's famous essay on this topic:

you can ask almost any programmer today about the code they are working on. "It's a big hairy mess," they will tell you. "I'd like nothing better than to throw it out and start over."

Why is it a mess?

"Well," they say, "look at this function. It is two pages long! None of this stuff belongs in there! I don't know what half of these API calls are for."
[...]
The idea that new code is better than old is patently absurd. Old code has been used. It has been tested. Lots of bugs have been found, and they've been fixed. There's nothing wrong with it. It doesn't acquire bugs just by sitting around on your hard drive. Au contraire, baby! Is software supposed to be like an old Dodge Dart, that rusts just sitting in the garage? Is software like a teddy bear that's kind of gross if it's not made out of all new material?

Back to that two page function. Yes, I know, it's just a simple function to display a window, but it has grown little hairs and stuff on it and nobody knows why. Well, I'll tell you why: those are bug fixes.

Each of these bugs took weeks of real-world usage before they were found. The programmer might have spent a couple of days reproducing the bug in the lab and fixing it. If it's like a lot of bugs, the fix might be one line of code, or it might even be a couple of characters, but a lot of work and time went into those two characters.
[...]
When you throw away code and start from scratch, you are throwing away all that knowledge. All those collected bug fixes. Years of programming work.

Systemd is still at the early stage, where it can get away with this kind of bad design, but as more and more people start to use it and the never-ending list of Real World Problems starts to creep in, the systemd developers - and the distros that joined them - are goign to have one nasty mess on their ihands. It is going to be a nightmare to all of the bugfixes and real-world mess that was thrown away because it was "old".

We tried to warn them, and were labeled luddites.

Well, as B5's Londo Mollari put it:

"Ah, arrogance and stupidity all in the same package. How efficient of you."

As for the users that like systemd because "it works", this is probably true. When you simply want an appliance that "just works", systemd is probalby the better choice. When you have simple needs, an appliance is just fine.

Those of us that to not want an appliance, non the other hand, will keep our general purpose computers, because "ease of use" just isn't that important compared to the larger problems threatening those devices.

[1] Note: I didn't say "against systemd" - if YOU want to run it, you should. If systemd provides better features for your requirements, then that's great. This doesn't mean it fits everywhere or that is satisfies all possible requirements.

about a month ago
top

Ask Slashdot: Is There an Ethical Way Facebook Can Experiment With Their Users?

Endymion Re:Yes. It's called "informed consent." (141 comments)

> There is only a question of degree and depth of analysis.

I take it you didn't read the first half of my post. That is not the only difference between what is effectively a passive popularity contest that you happen to measure in revenu or subscriptions and an attempt to affect change in the emotions as an active result of my actions as a specific goal. Seriously, this is not a complicated distinction.

> The Common Rule does not apply here.

I see you are not up to date on varoius state laws. I suggest starting with Massachusetts.

> There's nothing objectively special about name-calling it "human experimentation".

Are you seriously not aware of the long history of unethical experimentation? Really?

Or are you taking offense at the comparison? Remember, the entire point I'm trying to make is that while experiments are a very good thing, because of very serious problems when it involved humans that have happened disturbingly often in the past, there is now an ethics requirement to get somebody else to sign off on it first. This is a trivial requirement for experiments like the one Facebook did. I expect that the tech industry could make some "internet research"-specific IRB that reduced the time involved to almost nothing, because by invoved at all, they discourage most of the problematic experiments from even being proposed.

> Every single person who is offended by this, seems to be on a bandwagon to nowhere.

So, not only are you not listening to what those people are saying, you bring out the content-free insults that don't actually address the arguments being discussed.

Nevermind; in return for your overgeneralization I'll just overgeneralize you as someone who is obviously invested in abusing their users and therefor blind to the damange they could cause. Just like arguing with the creationists, such people are not worth the effort; as Upton Sinclare said, "It is difficult to get a man to understand something, when his salary depends upon his not understanding it!"

about a month and a half ago
top

Ask Slashdot: Is There an Ethical Way Facebook Can Experiment With Their Users?

Endymion Re:Yes. It's called "informed consent." (141 comments)

This is true, of course.

Which is why so many people are angy at Facebook - they went far beyond simply changing the layout or pagination or similar features. Instead, they set out to see if they could manipulate the emotions of their users, by the indirect means of selecting bits of content that the user requested that had certain properties, and changing how they would be presented (effectively hiding those items for the testing period).

How they may have intended to improve user's emotions. By most external reviews, they were unsuccessfull and failed to have much of an effect regardless. None of that matters. You don't get to decide on your own to conduct experiments like that, even if they are well intentioned. (EVERY experiment is "well intentioned", at least by the experimentor)

Why is it that people who are supposedly highly educated, experience [observation: your low /. UID] and used to dealing with complex issues have such an insane ignorance with regards to the Common Rule? I know techie nerds/geeks (myself included) stereotypically have less than ideal social skills, but the this Facebook issue seems to have revealed a deep sociopathy and lack of empathy in most of the tech industry. It's like people simply cannot abide the idea that even trivial external checks - to prevent some of the serious problems that have happened in the past when people experimented without any oversight - and so they dream up all kinds of excuses and bad arguments to try and deflect the topic. I'll try and point out these problems, using your post as an exampole. (I'm not trying to pick on you personaly)

Changing how your website performs text output is not experimenting with users.

Total straw man, as that's not what facebook did. This might suggest a failure to read the acctual paper, or maybe some serious misunderstanding of the difference between changing your own product (to which people might react emotionally) and setting out to manipulate those emotions as a goal in itself.

There's no need for consent

That may or may not be need in an actual experiment. Which is why you ask the IRB, who can waive the consent requirement in some cases. Requirements such as getting Informed Consent only happen after you talk to the review board.

when I move a button, nor when facebook changes an algorithm.

Of course not. That kind of change is totally off topic.

Take a breath and reconsider.

This type of casual dismissal is what I was talking about above. It suggests to the rest of the world that they shouldn't trust the tech industry, because they apparently don't care about ethics issue or are frighteningly ignorant about basic social constructs.

about a month and a half ago
top

Ask Slashdot: Is There an Ethical Way Facebook Can Experiment With Their Users?

Endymion Re:ethical science (141 comments)

No, you don't get to get blanketly avoid informed consent simply because it makes your experiment *hard*.

You ask an IRB for a waiver, each time, like you're supposed to. The whole point is that you are not supposed to be running experiments *on humans* without supervision. We've had way too many problems with that in the past, and so the requirement of getting a 3rd party to sign off first was invented as an incentive against running unethiccal experiments.

For some reason, there are a lot of people that are *shockingly ignorant* on this subject. They see this requirement as some sort of hostile or confrontational situation. Well, who do you think staffs an IRB? Other scientists, of course. It's not like they want to prevent people from doing experiments. In many cases where the experiment is not possible under the usual rules, they can *grant waivers* to some of the requirements. Facebook's study probably would have been an example of that: initial consent waived or defered into a debriefing. Or something else - if you work with the 'IRB, maybe other workarounds to this problem could be found.

The point being, you don't get to make this descision on your own as the experimentor. /for details, check with your lawyer. Seriously. This stuff can be a *felony* in some situations, and some *state* laws are even stronger. A real lawyer is required in almost all cases.

about 1 month ago
top

Ask Slashdot: Is There an Ethical Way Facebook Can Experiment With Their Users?

Endymion Get approval of an IRB, like everybody else (141 comments)

The whole point here is that you need somebody else who is not the experimenter to sign off on the experiment when humans are involved. We call those people the IRB.

What's that, tech industry? You think a/b testing would be impacted? That's a popularity contest, not an experiment. Facebook's experimet had the specific goal of being able to manipulate the emotions of their users, which goes far beyond simply asking which website layout they find more attractive or useful.

What's that, tech industry? You think it would take way too much time if you had to get approval for experiments? Then throw together a multi-company group to found your own IRB. I'm sure there are universites that would be willing to partner with that group to lend their advice and help the group get started quickly.

What's that, tech industry? You think that there is not way you could conduct your experiments if you had to get proper informed consent, (which has specific criteria - an EULA or TOS does not count)? First: welcome to the club. Sometimes, doing proper and ethical experiments is hard. Many disciplines have tog deal with that, and I guarantee it is easier to find alternative ways to test your theories about "social media" than it is for the psychologist trying to investigate complex mental health issues, and both of those areas of research get to skip the whole "untested, unknown, and probably horribly dangerous new drug" mess that some doctoroso have to find a way to test without killing the participants.

Worse - and this betrays the total and complete ignorance of the people at Facebook that ran this experiment - if they had bothered to ask an IRB like you are supposed to, there is a good chance they could have gotten some requirements such as having to get informed consent in advance could have been waived. Their experiment simply wasn't that risky, compared to most experiments involving human testing.

TL;DR - If the tech industry decided to work with the process and bothered to ask an IRB, they would have avoided a lot of bad PR. Their failure to do this - and their insistence afterwords that even a trivial "trust but verifyf" is the kind of thing that only applies to *other people* only serves to make people fear the entire insutry. Justifiably. Would you want to buy stuff from people that avoid every ethics regulation?

Of course, I haven't addressed any of the state laws, some of which have even stronger requirements...

about 1 month ago
top

Fork of Systemd Leads To Lightweight Uselessd

Endymion Re:launchd (469 comments)

I'm not talking about *init systems* - systemd was never "just an init system". Remember, it's absorbed stuff like network management and system authentication. That kind of feature often requries linking to (L)GPL code, and you can trigger the GPL's requirements depending on how you do that.

So Poettering wants to move all those function calls to (k)dbus. In his own words, "... the primary interfacing between the executed desktop apps and the rest of the system is via IPC (which is why we work on kdbus and teach it all kinds of sand-boxing features)".

about 2 months ago
top

Fork of Systemd Leads To Lightweight Uselessd

Endymion Re:Not a boycott but a confirmation (469 comments)

That's exactly my point. I'm suggesting the goal is to avoid making a derivative work. The GPL describes various ways to recognise a project as having "derived" from covered code, and linking copyleft and proprietary code together is one of them. (with some variation depending on if we are talking GPL or LGPL).

Remember that one of Poettering's goals is, in his own words, "... the primary interfacing between the executed desktop apps and the rest of the system is via IPC (which is why we work on kdbus and teach it all kinds of sand-boxing features)".

The point is if I want to do (for example) some sort of user authentication, I may have to link against libpam.so. This is something that would be reasonably commoon in embedded systems, and linking covered code into your embedded device (and having to distribute libpam.so with your product) could easily be a derivative work. (details matter, ask your lawyer about specific projecs).

Once absorbed into Poettering's project, you avoid all that risk because you don't interface with the system features directly and instead use "local RPC". This changes the project from being a potentially infringing derivative work into something that merely uses the tool. Merely using a tool that is licenced under the GPL is explicitly excempted, as the GPL only coveres redistribution and not use. ("GPL is not an EULA") This is a major change in legal status for your typical embedded device, which often wants a minimal OS to host their embedded app. They would also really like to avoid having to deal with the handling anything GPL. Changing to "local RPC" for all system interaction neatly fixes that problem.

We don't run across this pattern with traditional RPL tools, because it's bad for performance to needlessly serialize everything when you could simply call a function directly.

about 2 months ago
top

Fork of Systemd Leads To Lightweight Uselessd

Endymion Re:Not a boycott but a confirmation (469 comments)

The traditional RPC tools don't force a chane in API for local requests - they link against the same traditional .so file that any local app would use. That is very different from forcing dbus to be the only exposed API even for local use. Apache may provide features over sockets, but apxs(1) still exists and apr.h still exposes a traditional API.

I'm not a lawyer either, but this is obviously unexplored territory for the GPL (which doesn't have a lot of court precedent regardless of the current issue.

It's not like we'll ever find some smoking gun proof. This is simply the best theory I've heard.

about 2 months ago
top

Fork of Systemd Leads To Lightweight Uselessd

Endymion Re:Not a boycott but a confirmation (469 comments)

You're thinking desktop. GNOME is the leverage to force the change, not the end goal.

There are a very large number of devices out there running Linux in an embedded environment. These devices often have code running right on top of the minimal bootstrap/init tools.

about 2 months ago
top

Fork of Systemd Leads To Lightweight Uselessd

Endymion Re:launchd (469 comments)

systemd is designed to replace APIs based on {static or dynamic} linking with the dbus/kdbus IPC mechanism, as a way to use (L)GPL libraries without being bound by the (L)GPL.

Note that despite uselessd's much saner approach to technical features, the exposed dbus API is still requried. Switching to the uselessd implementation still enables this new type of "tivoizaiton".

about 2 months ago
top

Fork of Systemd Leads To Lightweight Uselessd

Endymion Re:Not a boycott but a confirmation (469 comments)

That's the whole point of all of this mess: {,k}dbus

Neither an init system nor vertical integration are the goal. The one consistent thing in all of the "systemd mess" is to leave the actual implementation officially a moving target where the trditional .so based library APIs are either hidden and undocumented or they are left out entirely. This forces you to use an IPC mechanism (dbus/kdbus) instead of simply linking to the functions you need and calling them directly. Forcing data to be serialized/unserialized so it can be sent over IPC is not nearly as efficient as calling a dynamically loaded local function. The systemd people love fast thing ("boot time!", etc), so why would they require this slow IPC everywhere?

*** if you never need to link to a library to use it, you can "link" to and distribute GPL code without being bound by the GPL. Poettering's cabal and systemd is an attempt to enable a new form of "tivoization" ***

If you are technically only "using" a library (no linking, no modifications to the library), you have not "infected" your proprietary code with the GPL. It's slower, but computers got fast enough that it doesn't really matter.

The nasty part is that by forcing arbitrary incompatable interface with systemd, to run stuff like GNOME you have to provide the key dbus features even if you don't use systemd. The end-run around the GPL still works with uselessd or any other "systemd replacement".

Unfortunatley, Lennart's cabal has everybody discussing technical features so this obvious goal isn't even addressed.

about 2 months ago
top

Torvalds: No Opinion On Systemd

Endymion Re:So what's wrong with systemd, really? (385 comments)

Flamebait? I thought this is the new standard for discourse with the systemd cabal. *sigh*

Applogies if it seems harsh; consider this Linus style "strong opinions". When you've used linux all the way back to kernel 1.2.13, watching coup to turn linux into windows hits hard.

about 2 months ago
top

Torvalds: No Opinion On Systemd

Endymion So what's wrong with systemd, really? (385 comments)

(paraphrasing a previous post of mine, becuase more people should see this)

It breaks existing promises, and makes few new promises in return.

There has been a lot of talk about the various technical problems with systemd and its developers inexperience-betraying design decisions. As bad as those are, they miss the larger point. There has also been a lot of very important talk about philosophy of design ("the unix way") that again shows how little experience the developers have and their disregard for the work people have already done and will have to do to fix the systemd mess.

These topics are valid, but miss the larger problem that systemd represents and the threat it is to Free Software in the Linux ecosystem.

## The problem with systemd's design: embrace and extend ##

As an excuse for all the vertical integration Poettering's cabal have been busy aglutenating into what they still sometimes claim is "justs an init system" has been the laughable claim that systemd is in any way "modular". They claim that "modular" is a *compile time* feature, or some property related to the fact that they build several ELF binaries. This is not modular, because it does not represent some form of stable, well-defined API.

What is an API (Application Programming Interface)? It's not a technical feature. It is not documentation that describes how to use some set of features. It is not a calling convention. So what is it?

An API is a PROMISE .

It is a social feature, not a technical one.

The functions and documentation are just a particular implementation of that promise. The key attribute that makes an API an API is that it is a promise by the developer: "If you want to interact with some feature, this is the way to do so, because while other internal stuff may change at any time, I promise this set of functions will be stable and reliable".

Binding previously-separate features into one project is bad design, by itself, the problem with systemd. The problem came when Poettering stripped down the barriers betwen features with the specific goal of removing established APIs (and breaking existing promises that developers relied on). His stuff may compile into various separate programs, but Pottering is very careful to keep various key interfaces "unstable" (despite being good enough for RHEL), specifically to not make any promise about how those interfaces will work in the future. He likes to call this hididng of interfaces "efficency" or "removing complexity". What he never mentions is that many of us used those promises, and by removing them he has at best forced others to do a lot of work to fix the breakage, or at worse made various features impossible.

A good example is logind, which was absorbed into systemd just so promises about its behaviuor in the future ("stable APIs") could be removed.

The reason many of us that have been watching Poettering's cabal for many years now suggest these changes are intentional and malicious are based on this. Occasionally removing features because of a technical need or bug or security requirement is understandable. Purposfully stripping out entire sets of features - that is, the features that allow other groups to develop with confidence that some feature they won't simply vanish - is something entirely different.

If MS acted like Poettering's cabal and removed a formerly-public API that competetors used - while promoting their own product that happens to use internal, not-publicly-promised APIs, the world would be screaming "monopoly". This happened, and resulted in several high-profile court cases.

## systemd threatens the GPL ##

It goes without saying that many people would like to distribute various GPL licenced software and not be bound by the terms it requires. The fact that some of these same people use the courts to threaten people who do the same to their software is noted, but off topic for now. The problem is the linking clauses in the GPL. Link the wrong way with GPL software, and the so-called "viral" nature kicks in.

Systemd (via kdbus) are an end-run around this. By calling function calls "IPC", you don't have to link to the GPL licenced code. A lot of players are willing to take the loss in performance for the benefit of distributing GPL software "unmodified".

You may have noticed the "systemd way" (and to some extend, the "gnome way") has been to ONLY provide access across dbus (soon, kdbus) instead of providing a local library .so and .h you can use directly. When the "local" forms even exist, they are often poorly documented and usually unstable. You may have also noticed that for "compatability" (by fiat), the "not-systemd" replacements tend to talk over dbus, as that is the mandated "correct" interface.

Embracing and extending linux with systemd is only a tool. The goal here is a new form of "tivoization" - to let proprietary business use GPL code while never opening up their part.

Is this really what you want to support by using systemd?

//now that you know this, guess what the point of systemd's control of cgroups is really about

//hint: think proprietary/GPL isolation

about 2 months ago
top

NSA Director Says Agency Is Still Trying To Figure Out Cyber Operations

Endymion Re:They are pretending that they do not know (103 comments)

Admiral Rogers,

The anonymous letter above has some good ideas about respecting the Constitution. You swore an oath to defend that social contract, and that oath is one of the most respectible American values I know. i know nothing about you and your history, so I respectfully - and hopefully - give you the benefit of the doubt and assume that has an American Admiral, you understand words such as "oath", "honor" and "duty" better than most.

  The duty to defend the Constitution is not an easy one at times, but it is something your fellow citizens will respect. The would even come to aid you if you should need them; you only have to ask. Open up the whole problem, without the usual spy-talk filled with obfuscation and dissembling, and ask the many intelligent men and women - your friends and neighbors. The internet seems help us solve even complex problem when we work together. Yes, this might require retreating from some current investigations; the investment you would gain by having support by working with your fellow citizens will more than make up for any short-term losses. Call if a "strategic retreat", if you want.

The previous anonymous letter mentioned a key point:

if You've already hinted at part of the solution -- differentiate between a cheeto-stained guy in a Guy Fawkes mask, versus a PLA, FSB, or NSA operative who's actually trying to do economic harm to America...

This is a key idea, and the NSA - or, possibly, this country - cannot last if the intelligence community is undermining the rest of the country. We have already seen billions of dollars in damage over this, and cannot take much more. As a suggestion on how to address the problem targeting your collections, you may want to consider re-hiring William Binney and Thomas Drake. Their original program known as THINTHREAD may not be the ultimate solution to this situation, but the ideas it had about encrypting all captured until an individual warrant is provided seems like a good place to start.

This country, more than ever, needs people to defend the Constitution. It's a simple document, with good ideas. Now, more than any time in the last two hundred years, has our founding document and highest law needed defending. It has threats that are foreign, and even larger threats that are domestic.

Admiral, I do not envy your position and the hard challenges ahead of you. Fortunately, your oath makes the path ahead clear. Good luck and godspeed.

/not posting anonymously, because I stand behind my words

//just like I stand behind the right to post anonymously by anybody who so desires

about 2 months ago
top

GSOC Project Works To Emulate Systemd For OpenBSD

Endymion Re:Oh well ... (314 comments)

This would be hilarious if it didn't imply such a terrible future for Debian. In the infamous debian-ctte arguments, one of the big reasons the systemd advocates insisted it was so important to only use systemd was their claim that maintaining multiple options would be far too much work.

I think it was only Ian Jackson that truly recognized that this wasn't a complaint about workload - it was a threat that systemd would become a moving target should Debian fail to conform.

about 2 months ago
top

GSOC Project Works To Emulate Systemd For OpenBSD

Endymion Re:Oh well ... (314 comments)

The thing the inexperienced systemd developers (but I repeat myself) do not understand is that "modular" isn't about some technical detail such as how you compile various features. For example, busybox intentionally compiles everything into one big binary. The features it provides, on the other hand, are still very modular in the UNIX sense. The key difference is that the tools busybox provides ("cat", "wc", "mkdir", "dd", and many others) all implement well defined APIs.

What is an Application Programming Interface (API)? It's not some function you can call, or the fact that a program understands some option ("--foo"). It is not even the documentation that may or may not be provided that describes how to use some feature. So what is it?

An API is a PROMISE .

It is a social feature, not a technical one. The functions, options, and documentation are just the technical implementation of that promise. The key part of an API is that it is a promise by the developer that if you want to interact with some feature, this is the way to do so, because while other internal stuff may change at any time, the promised API will be stable and reliable.

The problem with systemd is exactly this. Pulling a n00b move and agglutinating various features into one project is annoying and not recommended, but it is not, on its ownn, a reason to avoid systemd. The problem came when Poettering stripped down the barriers betwen features with the specific goal of removing established APIs. His stuff may compile into various separate programs, but Pottering is very careful to keep various key interfaces "unstable", specifically to not make any promise about how those interfaces will work in the future. He likes to call this hididng of interfaces "efficency" or "removing complexity". What he never mentions is that many of us used those promises, and by removing them he has at best forced others to do a lot of work to fix the breakage, or at worse made various features impossible.

A good example is logind, which was absorbed into systemd just so promises about its behaviuor in the future ("stable APIs") could be removed.

The reason many of us that have been watching Poettering's cabal for many years now suggest these changes are intentional and malicious are based on this. Occasionally removing features because of a technical need or bug or security requirement is understandable. Purposfully stripping out entire sets of features - that is, the features that allow other groups to develop with confidence that some feature they won't simply vanish - is something entirely different.

If MS acted like Poettering's cabal and removed a formerly-public API that competetors used - while promoting their own product that happens to use internal, not-publicly-promised APIs, the world would be screaming "monopoly". This happened, and resulted in several high-profile court cases.

So go ahead an prove that you don't know what you're talking about and assert that systemd is in any way "modular", when non-modularity was an explicit goal behind systemd. The rest of us are choosing to not go along with Poettering's attempt to embrace and extend Linux into a cheap, buggy, feature-free windows clone.

about 3 months ago

Submissions

top

Updating Social Sites Requires Member Buy-in

Endymion Endymion writes  |  about 10 months ago

Endymion (12816) writes "In 2007, the forum known as "Fark" suprisd their members with a new site design. This caused a larger portion of their membership to walk away. Many people blame the a staff member's choice to throw gasoline on an already badly-flaming discussion thread and posting the now legendary dismissal "You'll get over it". Years later, though, Fark staffer Joe Peacock gave a talk discussing what went wrong: they scared their members away by not involving them in the upgrade process, disrupting what people saw as their "hang-out spot". The lessons in this talk are something every "social" site needs to understand — the site needs its membes, and the members don't need the site; disrupt their habits at your own peril!"
Link to Original Source
top

Label printer recomendations?

Endymion Endymion writes  |  more than 5 years ago

pdkl95 writes "I have been using some small, simple desktop label printers for quite a while now. Unfortunately, it's rapidly becoming clear that my printing needs are for something far more "industrial strength". Several of the label printers have failed, and they never really had the management features I wanted.
So, does anybody have recommendations on label printers, that can hold up to a quite heavy load? The catch is that I'm printing to them from CUPS under Linux, and it seems like specialty-printers are a windows-centric field."

Journals

top

"Feckless Imbroglio"

Endymion Endymion writes  |  about 10 months ago

Do you remember which person was such a miserable failure? While Google made their search engine a lot more resiliant to the simple tricks such as that Google Bomb, I suspect many of you immediately knew exactly to whom I was refering. The phrase "miserable failure" are not only an amusing technical trick - it is also a powerful sound-bite that served as a useful reminder, social identifying mark, and common rallying cry.

I propose we use a similar "catch-phrase" for the NSA when discussing the mess they have caused: feckless imbroglio. The unusual word-choice is intended as a non-technical discussion point, as far too many people are alienated by the technical nature inherent to any discussion of the NSA. It may not do much, and it's highly unlikely to grab the "I'm feeling lucky" button, but slogans, brand-names, and catch-phrases can reach some of those people that are turned off by spying, computers, or other technical discussions.

Slashdot Login

Need an Account?

Forgot your password?