Follow Slashdot stories on Twitter


Forgot your password?
Note: You can take 10% off all Slashdot Deals with coupon code "slashdot10off." ×

Comment Re:Whoever pays the bills (Score 4, Funny) 154

How a plan becomes policy

In the beginning was the plan.

And then came the assumptions.
And the assumptions were without form.

And the plan was without substance.
And darkness was upon the face of the workers.

And they spoke among themselves saying,
"It is a crock of shit and it stinketh."

And the workers went unto their supervisors and said,
"It is a pale of dung and none may abide the odor thereof."

And the supervisor went unto their managers and said,
"It is a container of excrement and it is very strong, such that none may abide by it."

And the managers went unto their directors, saying,
"It is a vessel of fertilizer, and none may abide its strength."

And the directors spoke among themselves, saying to one another,
"It contains that which aids plant growth and it is very strong."

And the directors went unto the vice presidents, saying unto them,
"It promotes growth and is very powerful."

And the vice presidents went unto the president, saying unto him,
"The new plan will promote the growth and vigor of the company, with powerful effects."

And the president looked upon the plan and saw that it was good.
And the plan became policy.

This is how shit happens.

Comment Re: Thanks anonymous reader! (Score 1) 294

Why is it that so many people seem to think that it's no big deal to open a connection to a random host on the internet? That puts you in yet another situation where you have to enumerate badness.

In this case, what you just described allows someone to probabilistically verify that someone saw a page (regardless of how they got the HTML - email/spam, HTTP, or a README.html found in a warez .zip). Marking links as prefetchable is something the malicious party can do on their own, so it offers zero protection, and a single packet all that is needed to track you.. Of course, we're not talking about a single packet, as this stupid "feature" does the entire transport layer including the SSL connection, not just the TCP 3-way-handshake.

I suggest thinking long and hard about what any of this data can be correlated with (temporally or as a matching surrogate key), remember that it doesn't have to work all the time. Single data points are usually safe on their own, but the pattern that emerges when you join someone's data trail together can be very detailed.

We need a reduction of data that browsers transmit, in this post-Snowden world.

Comment Re:What's the point? (Score 2) 216

I'm even fine with changes that break existing software if it is required to fix a security issue. Unfortunately, we have people confusing design with implementation, and even more that follow the Not Invented Here principle. Anybody in that camp may want to read "Things You Should Never Do" by Joel Spolsky.

When programmers see an old, messy project they tend to want to rewrite it. They see that mess and believe they know how it could "obviously" be simplified. Usually, this is incorrect, as the simplified abstraction they are picturing doesn't actually implement the same feature. That "mess" was actually the accumulation of important details that were learned over time: subtle details that were not covered by the original design, evolving requirements, and expensive bug fixes. The "rewrite" has none of that, and those details will eventually be added back, eventually making the rewrite just as messy as the original version at the cost of many man-years of effort. Throwing out the "mess" is throwing out a project's most valuable asset: real-world experience.

Comment Re:What's the point? (Score 0) 216

Hmm....a n00b that doesn't understand good enginnering practice? (Do you buy new screwdrivers every few years to keep up with useless changes? If you want to keep you Philips or Torx screwdrivers, you're just afraid of change)

Or a shill that is trying to use identity politics and tribal politics to drive a wedge through the Free Software community?

Or should we just go with "idiot"?

Comment Re:What's the point? (Score 2, Insightful) 216

Did you miss the GTK+ 3.0 drama?

The GNOME idiots have been making it a point to break compatibility and remove "old" (aka "working", "currently used") features. You are delusional if you think they will continue supporting X once they declare the Wayland version to be "standard".

Of course, they'll probably use their typical victim-blaming approach where claim that keeping the old version around is "too much work" that should be done by someone else.

Comment Re:What's the point? (Score 2) 216

You are aware that X has an extension system, right? Or are you just leaving that part out in an attempt to pretend that the backwards compatible development style of X for some reason requires that no new features have been added? Also, your nonsense about ancient versions of X providing features similar to the limitations of ancient hardware have nothing whatsoever to do with the basic principles of the X Window System.

Supporting new features does not require removing old features - they are simply moved into "extensions". In no way does this limit the performance of those features. The idea that we need to remove the older non-extended protocol to support newer features is not only wrong, it's terrible engineering.

So which are you - a n00b that needs to learn how X (and good engineering practices) actually works? Maybe you're just a sociopathic troll? Or is this profit based and you're trying to push someone's agenda? (perhaps RedHat?)

Comment Re:kdbus, where are you? (Score 1) 110

It's not clear that it's actually required.

It's worse than that - not only is it not clear that it's actually required, I (and other) want to know why they aren't just writing a simple userland library that uses TIPC, which is already in the kernel. Even if there was some legitimate reason to need a kdbus-like feature that that wasn't already supported by TIPC, wouldn't it make a lot more sense to extend that existing, already debugged code and extend TIPC with the that feature?

Comment Re: Systemd (Score 1) 110

Systemd doesn't force anything on me because I don't use it, and have a much more stable system because of it. If I werre to run systemd, it *absolutely does* force an increasing number of policy decisions and questionable quality code on me.

This is what I meant when I said about how apparatchik tend to their personal requirements and opinions on to others. You are making a failure of induction, by assuming that just because you haven't personally seen any problems with systemd,, those problems must not exist. Systemd makes major policy decisions that are probably not going to get in the way of "most"1 people, but it definitely gets in the way. Oh, and who said anything about "SysV scripts"? You do know that "init" is only a tiny portion of systemd, right? Moist of the problem with systemd have absolutely nothing whatsoever to do with "starting jobs".

Of course, with all that crap about systemd being a modular design (it's not - modular doesn't refer to how many binaries it compiles into) - which is only part of the unix philosophy - and blatant falsehoods ("doesn't take away any feature"), you're clearly either as a troll, shill, or useful idiot. I normally wouldn't bother feeding such nonsense, but....

The main reason I'm replying is to point out that the serious reading comprehension issue: you seem to have:

basically what you are arguing for is that people should not be allowed to have Systemd's features or be able to use them.

No, that isn't what I said at all, and it say a lot about you systemd apparatchik that you have to lie and misrepresent anyone who criticizes systemd into being a "hater" trying to suppress anything ("not allowed"). That has never been the case.. If you had actually read my post, you might have noticed I specifically said that if systemd works better for you or is just nicier in some way, then use it. I'm glad you found software that works better for you. Maybe you culd you show your fellow Linux users some courtesy and refrain from making up lies and accusations about anybody that doesn't run systemd?

My main thesis wasn't even about system directly, and instead address the misconception that features (such as cgroups) were somehow unavailable without systemd (either today or in the past).

Comment Re: Systemd (Score 4, Insightful) 110

What, exactly, are these linux-specific features that systemd supposedly makes available? You certainly don't need systemd to use cgroups, which were usable before systemd tried to monopolize the project.

"Usability" is personal opinion, and if you find systemd's management of cgroups management to be easier than the other options, than use it; we don't *have* to agree on such details, thanks to the flexibility of Free Software.. After all, the usability of a tool depends on what your particular goals and requirements.

So please,, stop spreading the misinformation and revisionist history that has is popular with many systemd advocates. Very few of the commonly stated benefits of systemd are new, and most were available - and in use - before systemd showed up.- it just became popular to ignore history and existing projects.

Oh, and iff you were trolling, then this is a sadly a typical example of systemd apparatchik: repeating popular misconception, arguments based on the projection of personal requirements and opinions, and quick to throw around moral accusations and insults. The person you were replying to may be a bit misguided and hyperbolic, they are not entirely wrong, either.

Comment Re:They will care, probably sooner than they think (Score 1, Insightful) 128

Even this is something journald does so much better than syslog

You are cherry-picking the one thing that isn't logged by most syslog daemons by default,, in a disingenious attempt to show that syslog is "worse", even though it is off by default because it is of little use. If we cared AT ALL to have the "log level" information, it would be logged.

The discussions of the many limitations of syslog,

Fine. Then solve the problem where it should be solved, and add this to /etc/syslog. You systemd apparatchik like editing non-script-based config files, right?

# probably already in the config
source src { system(); internal(); }

# here's your damn filter
filter f_err_only { level( "error"}; };

# pre-filtered log output
destination err_only_log { file("/var/log/err_only_messages"); };

# link the filter to a destination
log { source(src); filter(f_err_only); destination(err_only_log); };

Now you can read those messages only using "less". You DID know that syslog has very flexible log routing and filtering capabilities, right?

claiming that regular expressions are easy is laughable.

If regex is too hard, you might as well give up now. Regex is only hard if you abuse it badly, which is true for any programming language. This is just trolling at this point.

Oh, and thanks for admitting you are an inexperience n00b. You may have been using linux since the early slackware days, but didn't seem to learn much.

As for your "challenge", I have yet to see any systemd apparatchik rise to the challenge to prove that systemd isn't an unmaintainable monolithic mess, by showing how to replace (NOT CHAIN) journald with syslog-ng or indeed run any of the systemd components in isolation.

Comment Re:They will care, probably sooner than they think (Score 1, Insightful) 128

Being able to do a "journalctl -b -1 -p err" is so much better than faffing around with grep and regex.

That statement alone shows the core problem with the systemd evangelists: you don' t want to learn generic tools, and instead want to use single-purpose, monolithic[1] apps. A key distinction between the two this windows-style "fancy speciality apps" idea and the design goals of UNIX-like environments is that someone has already implemented the query you want to ask the computer to run.

It's great that you found a useful way to view your log data. Now try to query on something that journalctl didn't already implement for you. What kind of query? I don't - and that's the point. We can't predict the future, and new problems show up all the time. The point of what you call "faffing around with grep and regex" is that those tools are not difficult to use, and once you are familiar with the basics you now have a general tool you can apply to any unexpected situation.

syslog severity level "error" and above

I have never even remotely needed to filter events by syslog(3)'s "level" bits - it's not a very reliable filter, as app can be inconsistent in what LOG_* flag they use. Filtering on the facility (source) or time is far more useful. If you find that particular command to be useful, then great - which would be a good example of how use-cases can vary a *lot* depending on what you're doing.

try that with grep!

Listen, if you want lessons on how to use basic unix tools, there are many available on the web. For now, what you're obviously missing is that you would use sed for range filtering, not grep. do the line-range filtering. You simply use two regex in the form sed -n '/start_line_pattern/,/end_line_pattern/ p'.

Then, once you have a useful query built with the standard tools, you save it in a 2 line shells script. Seriously, do you think we actually type this stuff out verbosely every time we want to search a logfile? Have you evne *used* a CLI? This is n00b level stuff.

how can systemd ever make it harder for non-systemd distros

If you're going to accuse someone of being misinformed, it's a good idea to actually know what you're talking about. To name the most obvious example, it is absolutely insane to have any specific application (server daemons included) depend on any particular "init system"2. Yet systemd promoted the idea of using sd_notify which created a link-time dependency. Yes, such things can be compiled out, but that misses the point. Introducing a binary, link-time dependency like this has the de facto effect of forcing distros to make an all-or-nothing choice about including systemd.

It is true that this is not entirely systemd's fault - the app/sever authors are also to blame for going along with this crap. That doesn't excuse all the social pressure Poettering's cabal put on a lot of projects.

1before anybody trolls with the usual response that systemd is not monolithic - probably by mentioning the number of binaries it compiles into - you should know that those claims will only prove you haven't actually understood what we mean when we say "monolithic"

2 this is why it was always a lie to call the systemd takeover a debate about "init systems", as systemd was never just an "init system", but also many other things as well, mostly inseperable by design

Comment Re:Stupid ... (Score 4, Insightful) 126

It is dangerous to assume stupidity - especially when the people in question are making threatening gestures in your direction. What you describe is one possibility. Another is that these lawmakers (or the people they work for) DO understand these issues, and the inevitable problems that arise are the expected outcome.

Yes, Hanlon's razor is a good heuristic most of the time, but in this case we have a pattern. Technology that empowers people (e.g. real crypto/security, better communications technology like the internet) has been attacked fairly consistently. Tools and methods have been criminalized in the past with alarming frequency. For this specific issue, there are a lot of people invested in the status quo of where computers ("ii.e. "most products", eventually) are easily monitored/tracked, and easily attacked if the need arises. Dan Geer described our situation very accurately in his outstanding talk last year: the current strategy of the US government (and others) with regards to network security is "all offense".

When proposals like this happen, people are tying to shape your future. Maybe they want to get an actual law passed. They just want to use a confusing topic in a show for the benefit of their constituency. Maybe the goal is propaganda or shifting the Overrton window. Whatever the purpose, we would be lucky to have stupid lawmaker which we can at least attempt to fix with education. Unfortunately, what looks like stupidity is often agenda, and underestimate their threat at your own peril.

Comment Re:disable EME (Score 1) 371

Firefox tried to push open video formats, like webm, and refused to support H264.

I know - I argued against that stupid strategy at the time. part of my argument was the same one Mozilla is using now (give up the fight or risk of losing market share).

My solution is still the same: don't ever implement evil or you make the problem worse, do what you can to satisfy market demands by dodging the problem (leave the codec outside of the browser by calling standard OS support (even gstreamer/etc on linux supported h.264 at the time). By ignoring h.264 years ago, Firefox lost users. By adding DRM support, they lost their remaining moral high ground and ability to fight future industry demands. (if they accepted industry demands once, they will do it again in the future).

"plugin" that is very restricted on what it can do

It would be a hasty generalization to assume that this will always be the case. Describing the current implementation does not indicate how it will be implemented in the future. A better extrapolation is that the probability of Mozilla accepting even worse DRM into Firefox in the future is high, because the reasons for accepting it now only grow stronger with time. They wanted to avoid alienating users that supposedly demand Netflix support in the browser. That demand will only increase dramatically when everybody is accustomed to using Netflix in Firefox.

Do you really think Mozilla will put their foot down when the ebook industry gets together with the movie industry to enable text DRM? Or when the plugin changes and requires new holes in the sandbox (e.g. to support Intel's new SGX instructions to create a Trusted Execution Enviornment you cannot access)? You really think that Mozilla will reverse their current behavior, accept the even larger damage to their market share as the Netflix users move to "a browser that works"? No, they will keep paying the industry's demands for danegeld and we lose the free and open web. When lots of the web is wrapped in DRM, do remember that you helped create that future instead of fighting early when the battle was easier.

"The fundamental principle of science, the definition almost, is this: the sole test of the validity of any idea is experiment." -- Richard P. Feynman