Follow Slashdot blog updates by subscribing to our blog RSS feed


Forgot your password?
Slashdot Deals: Deal of the Day - Pay What You Want for the Learn to Code Bundle, includes AngularJS, Python, HTML5, Ruby, and more. ×

Comment Re:David Edmundson answers your questions (Score 1) 429

You don't want closing the lid to automatically sleep the system?

As a matter of fact, I don't. But that's irrelevant. That kind of stuff was already handled by existing stuff. You could make it so that closing the lid locks, sleeps, or locks and sleeps, all within programs that already existed and worked.

You think it's better if the desktop environment includes the code to put the computer to sleep? I thought you didn't want monolithic code, you want code split into separate areas of concern?

I never said the DE itself should handle anything low-level with sleep, just that it would tell some other program to put the computer to sleep. Programs which already existed and worked.

Many parts of systemd are just solutions looking for problems. Same as Pulse "it works except when it doesn't" Audio, 99% of systems have no need for Pulse, and there are probably more machines that run into bugs with Pulse with the stock config than without Pulse.

Comment Re:David Edmundson answers your questions (Score 2) 429

SystemD is a collection of small pieces of software. Together it makes a big system but you probably haven't paid any attention to it.

Not this argument again.

It doesn't matter how many pieces something is if the pieces are more or less inseparable. There's a reason all of those things are developed under the "systemd" banner. If you decide that you absolutely must have systemd without the crap you don't want, your only option is to configure and compile it yourself. If that's "modular" or "not monolithic", then I guess Windows is too.

If it were truly not monolithic, then I'd be able to install systemd's non-init stuff on a sysvinit system and vice-versa.

So you are saying that if it doesn't work as promised, it will suck and be broken. You just somehow know it will suck even though it's not done yet. Have you ever closed the lid on a laptop, then later opened it and found it displaying all your desktop windows and then going to the unlock screen? I hate that.... if this does work as promised, I want this.

Much, much easier solution to this problem:
1. You press suspend button
2. DE's hotkey handler catches this, tells screen locker to lock
3. Screen locker reports back that the screen is locked
4. DE then puts the computer to sleep.

Same strengths and weaknesses without ever going outside the DE except to tell the system to suspend.


Comment Re:David Edmundson answers your questions (Score 1) 429

That's really strange, I seem to recall Linux DEs having user switching features long before systemd. Inhibitor locks cause more problems than they solve (e.g. I press the suspend button, put laptop in bag, oops now it's overheating because it never actually finished going to sleep). For most of the other stuff there's no good reason for it to be monolithically lumped into one big piece of software.

The actual end-user benefits of systemd (like boot times) get completely overshadowed by their idiotic fixing of things that weren't broken to begin with. It's not like a modern DE is massively better than one 5 years ago, so stuff shouldn't be getting more complicated under the hood. Most of the stuff you listed already was implemented outside the init system, so if it's decided that those things are desired by multiple DEs, then they can simply be implemented in a generic version that still exists outside the init system.

Comment Re:The judge got paid on this one. (Score 4, Interesting) 72

But they weren't getting notices that people on the service were violating the law. They got notices saying that the *AAs believed that their customers were violating the law. There's no hard evidence that someone who the *AA sends a notice to is actually guilty of that charge unless they do a proper investigation.

Comment Re:In other news (Score 1) 291

Think about how many businesses out there directly or indirectly are affected by the costs of transporting freight via trucks. If your business ships things to customers, you bear the cost of trucking. If your business receives supplies from vendors, you bear the cost. Reducing the cost of transportation benefits pretty much everyone to the point where I have no doubt that at least as many jobs would be created as lost. Reducing efficiency for the sake of jobs is really no different than the broken glass fallacy.

Comment Re:Bad practice. (Score 2) 242

I'd argue that a fingerprint is better specifically for phones, but falls flat in most other applications. iPhones have a touchID chip paired to the CPU, so they're extremely difficult to crack even if you have physical access. A well-done fingerprint system like touchID is great for the security of a local device. But it doesn't work well for anything remote, since a fingerprint can't be hashed which has numerous implications. It also can't be used directly as an encryption key.

Also, it's one thing to peek at someone's 4-digit phone passcode over their shoulder. It's an entirely different thing to try to get someone's password which may be really long or have lots of symbols as they type it on a computer.

Comment Re:So AMD called their Hyperthreading a CPU core? (Score 1) 311

It was wrong to buy a CPU without looking at benchmarks first. AMD's IPC is far worse than Intel's, to the point where in many workloads, a 4-core Intel will beat an 8-core AMD even if they didn't have shared FPUs. Remember when AMD had better IPC, and would even rub it in peoples' faces by naming their CPUs after the equivalent Intel Mhz? Well, now it's the opposite.

The trouble with money is it costs too much!