Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?
Compare cell phone plans using Wirefly's innovative plan comparison tool ×

Comment Re:White-washed submission (Score 1) 76

The point being a 'patent troll' is defined as some entity holding patents, but not actually *making* anything. Bad for both being a leech, but also challenging as the potential to fight back to pursue cross-licensing is impossible since the attack doesn't do anything.

Now if you think the patents are stupid and not worthy of being patent, that's something else and I'm particularly inclined to agree about the VFAT patent. But 'patent troll' is a specific phenomenon, and Microsoft is not (yet) in that role.

Comment Re:sounds nice, but... (Score 1) 538

Though one of the chiefly cited daemons (pulseaudio) is in the same ballpark with the same set of developers available to work it.

The problem with your logic is that at some point pulseaudio and the like could in turn decides it wants to declare itself as 'really wanting to persist' using the systemd mechanism, and again be running stray. Then systemd could add yet another layer of 'really *really* mean to persist. It's an arms race of crappy software. The question is 'why does the daemon *think* it needs to persist?' not 'how can we invent a way to ignore their request to persist and hope they don't update to the new scheme'.

Comment Re:sounds nice, but... (Score 1) 538

The point being that it's what systemd upstream decided would be a good default behavior. This speaks to the mindset of the architects and how it factors to their general design.

Yes when they offer choices, distros can opt out. However they are inventing new paradigms where existing ones already serve.

Comment Re:User friendly (Score 1) 311

I think there is a lot of room for improvement for reasonable defaults and auto-sensing correct behavior.

However I take issue with the 'highly intuitive graphical interface for changing the way it works' *always* being available. The GUI should really focus on the most frequently fiddled with things. In Microsoft, you can very rapidly need to drop to do things via powershell commandlets or registry edits to modify some hopelessly obscure thing. Similar in OSX. It's a rare circumstance and frankly the ability for a user to 'intuitively' figure out such an action is needed is just beyond reach.

GUIs that try to encompass *everything* are confused messes. Some KDE dialogs are dizzying, and they still aren't all encompassing. So be very careful suggesting that everything should have an intuitive GUI, because that really isn't the case for any general purpose platform (mobile OSes come closest, but mostly by virtue of not being at all configurable).

Comment Re:"professional"? (Score 1) 311

Well the point is the humble beginnings were Linus sharing a hobbyist project without much ambition. At the time, GNU was a big effort to produce a full Unix system, but licensed under GPL. Proceeding very carefully/slowly for things. Making sure they had the right plan in mind before going and executing to that plan pretty thoroughly. This worked fine for a lot of the system, but kernel wise there was a big gap.

So along comes Torvalds, with an appropriate amount of uncertainty, sharing his quick and dirty stab at a kernel. Ultimately his more pragmatic approach would lead to a usable system long before GNU could deliver one. As such despite not originally seen as a 'serious' attempt, n practice it is the backbone of a great deal of professional work, as well as the target of a lot of code developed professionally.

Comment Re:The way I would handle any important system (Score 1) 400

The generic sentiment is the same, part of the value of a software vendor is how much they can be relied upon to not screw you over in updates. When that equation starts not working out, the answer is not to create long term plans on how you are going to vet each individual minor upgrade, balance the risk of that update versus the risk of not applying it, and so on. The answer is evaluating a long term move to another vendor. There might be some short term making the best of the current situation, but people shouldn't be looking at a long term 'just deal with it' workaround. To put it simply, if you can *credibly* do a better job of evaluating software updates than your vendor, you need to rethink your vendor relationship.

This is a somewhat subjective call and depends on the circumstances. I would say that MS has indeed compromised this value by laying off their QA team and going to a rolling release model and I won't use them for anything other than Windows gaming, but everyone has to make that judgement call based on their needs and such.

Comment Re:Hmmm how bad could it be? (Score 1) 538

I think dbus gets a pass *way* too much for the crap it causes. I think people only started noticing when systemd started to depend upon it so heavily for core function. Of course, a good criticicsm is that systemd shouldn't incur such dependencies for core functions, and that it shares some blame for dbus problems which used to only screw up desktop applications are now screwing with core services or servers.

Comment Re:sounds nice, but... (Score 1) 538

The short of it is systemd decided all of a sudden the 'right' behavior was to assume processes were killable when your shell exits, unless they took some special measures to explicitly inform systemd directly that it realy really really meant to persist. screen, tmux, et al were suggested to change to support yet another paradigm for indicating wanting to *really* stay alive after session logout.

IIRC, it was all caused because some processes like pulseaudio were abusing the existing paradigm of requesting to run in a way that would persist beyond session exit and failing to close themselves. Rather than correct those bugs, they decided it would be easier to introduce *another* layer of requesting such persistence.

Comment No auto-fsck please... (Score 2) 538

Unless you run it in check-only mode. I have seen systems blindly try to detect and *correct* problems in a filesystem cause tremendous harm. Even Windows prompts the user before taking such measures on removable media. The fact of the matter is you may have some unexpected situation that would be corrupted by that action. Maybe a newer version of the filesystem your version of fsck mistakens for corrupt. Maybe it had one type of partition table at some point now it has a new one you don't recognize, but you see a backup block and corrupt the storage by restoring backup block of what you do recognize.

The fact of the matter is, users should be asked/made to take corrective action in something like fixing a filesystem.

Comment Re:When everything you do (Score 2) 538

The thing is it works well, until something cocks up, then it's utter hell. The non-deterministic boot process is killer. I have had a hell of a time diagnosing systems where people have done things so root filesystem will not mount on normal boot. Then I try to boot single and it works fine, or rdshell. It turns out to be some crazy ass race condition between two things *no one* realized would be related, or should be related.

Also, things that were straightforward get strangely complicated. SysV init didn't care one bit about something like docker, but a lot of work and complication went on to coordinate systemd and docker.

I have more admins than ever requiring support and I can't fault them for being unable to contend with the mess they have been saddled with. It's more featureful, but it takes things too far making a lot of things impossible to reasonably debug. I personally would love to see journald eschew the binary-only logging and for systemd to offer a deterministic boot mode, where boot speed is compromised for the sake of repeatability.

It's not just old folks whining about change,, there are very concrete things that are being done incorrectly. Sure there are more nebuluous rants that may be either folks trying to get a rise out of the community or have a difficult time expressing their general frustration in a more concrete ways, but that's no reason to sweep the real problems under the rug along with them.

Comment Re:SystemD? (Score 1) 538

The one threat I don't get is people who claim to dislike systemd sometimes claim they will go to windows instead. Windows in general is managed in a very systemd like way, except more shoddy. I'm not a fan of how SystemD is going personally, but if it *had* to be Windows or Systemd, I'd pick systemd in a heartbeat.

Comment So Linux apps can make win32 calls? (Score 1) 228

That should make porting WINE easy!

Seriously speaking, it seems the short of it is that WSL should be disabled if AppLocker is desired. I suspect that wouldn't upset too many folks, as I imagine the intersection of audience that uses AppLocker and the audience that would use WSL is non-existent. AppLocker is a pretty extreme lockdown to inflict on your users, and I can't imagine those admins wanting to use Linux applications.

WSL can be disabled, so I don't think this is as large a deal as the article wants it to be. In fact I assume the default is disabled.

Comment Re:Unlikely...maybe (Score 2) 412

That was a downright 'friendly' approach. MS could start shipping in a mode that forbids anything but UWP by default, under some claim of improving the security of the platform.

They can (credibly) point to both Apple and Android as examples of platforms that have locked application delivery to their respective platform by default. Yes in Android you can enable sideloading (but you get shown a very 'scary' dialog about how risky it is and you really shouldn't do it), but as an application developer, you really have to let Google distribute it for you or else miss out on the market.

Slashdot Top Deals

C Code. C Code Run. Run, Code, RUN! PLEASE!!!!