Slashdot is powered by your submissions, so send in your scoop


Forgot your password?

Comment Re:What's the point? (Score 2) 216 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 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 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 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 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 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 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 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 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 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 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.

Comment Re:CDM is sandboxed (Score 1) 371 371

The current implementation is sandbox; we know nothing about how it will be implemented in the future. Have fun when a new version of the plugin requires disabling the sandbox or giving the plugin access to more OS features. When the servers drop support for the old version for vague "security reasons" (or other excuse), good luck telling the people that are now used to getting Netflix that the new version won't be supported. No, the sandbox will be removed and the new version made to work, with the same justification they you short-sighted idiots are using now.

Even better: are you going to go out of your way to block the upgrade when the ebook publishing industry (which already uses a lot of DRM) demands the same browser DRM rights as the movie industry? When Amazon makes the same demands as Netflix, why won't the same justifications work? // non-DRM webpages were nice while they lasted

Comment Re:Get cracking (Score 1) 371 371

in the end, the DRM'ed content has to be accessible


That's the key point - as long as you have the requirement that DRM content "must" be accessible, it the people that control that content can demand anything they want. You need to tell them the line you aren't going to cross, or the price you won't pay if you want the publishers to change. This is basic supply/demand economics. Infinite demand means the price can be anything.

Yes, this might mean some sacrifice from you, such as not getting to see the latest popular movie. Are you going to pay that cost now, or are you going to keep paying the publishers that demand more and more, so you have to sacrifice even more when the fight happens in the future?

Comment Re:Get cracking (Score 2) 371 371

Maybe you should start paying attention to what's going on in the world. Major power-grabs are happening and you think it's about movies, simply because the people trying to grab power said so. I don't give a damn about movies or Netflix. What I do care about is legal precedent, the establishing of standards that will be used in other areas, the erosion of rights like the 1st-sale doctrine, and businesses that demand you weaken your computer security.

If this looks like a dystopian SF novel to you , maybe you should start doing something about it instead of accepting whatever price the publishing industry (not netflix) asks for just so you can see the latest movies. Welcome to the War On General Purpose Computing. Some of us have been fighting that war for over 20 years now, trying to prevent the "dystopian SF future". It would be nice if other people joined the fight once and a while, because we're losing the war; a decade ago Mozilla would have never caved, but the pressure has gotten a lot worse.

Anybody discussing movies isn't looking at the larger situation, where some people are asking you to hand your computer's root access over to them, and you do it because thy promise not to abuse that power while threatening to take your toys away.

Never ask two questions in a business letter. The reply will discuss the one you are least interested, and say nothing about the other.