Well, with SSD, I don't necessarily have a problem with vibration. However the concept doesn't exactly excite me. Particualrly since it's general purpose, windows oriented means that headless interaction is going to be woefully limited, making that microphone array less intriguing.

Other vendors have done the stacking and it's not caught on, probably because of what you say in part, but for another there's relatively little they've thought to do with it. I can add what is not going to be much better than mono speaker, or I could add real speakers. Maybe with that and the phone controls they imagine this as a basis for a VOIP appliance, but again the general purpose OS means that will be limited.

Of course there is TOTP (which can use pretty much *any* compute device) and U2F (dongle required). Practically speaking, requiring one of these two neatly gets the Nonce behavior you desire (well, roughly, a phishing attack would get a token that would be valid for at least a short period of time).

I agree SRP was a nice concept, but in practice, no one is interested.

But then people would complain 'what if they had a slow internet and went to sip a cup of coffee or something' if the time is too short. The click-through idea seems viable enough. However I'm still skeptical that a user that would be vigilant about the address bar would suddenly stop being vigilant if the page clearly reloads. Either they are vigilant throughout or they would fall for a phishing page without ever touching google's servers.

If you are saying it is a code maintenance nightmare, then whether it is typed or not, your code must be spaghetti code if the overall line count significantly impacts your variables. Even in a complex project, things should be nicely scoped so that readability is preserved enough that lines of code does not impact whether static typing is a good idea or not. That's not to say it is not a good idea, just that the good idea is pretty constant whether the project is small or large.

Also, Java compiles to some abstracted bytecode. This is the case for pretty much all interpreted languages (just the compile step happens on 'load', and many languages make effort to cache that). Performance is governed by the quality of the runtime, and yese the JRE is one of the better language runtimes, though Javascript has had a *lot* of similar work, but the language is limited. Ruby, Perl, and Python do have runtimes that are far behind the JRE, but at this point more to do with relative investment in the runtimes than things enabled by the language (though yes there is a difference by having things like static typing, it's tiny compared to general optimization potential).

On GUI/Web, if you mean it's 'good enough', fine, but if you are claiming it is advantaged, it really isn't. Particularly on the Web side, Java really doesn't do *anything* for you GUI wise, it's just beyond the scope (unless you are saying applets, which no sane person would start new and in fact getting an applet to run in a modern browser is insanity). If you refer to Java webstart, for just make your app run in the browser already and not subject the users to the pain in the ass that is making sure javaws runs right.

On cross platform, nowadays it is extremely easy to have a write once, build everywhere. Now if you think the 'build once, run anywhere' is significant, then your build system isn't adequate and your users' lives are made more complex because they suddenly need to understand how to launch a jar, which is somewhat unnatural for all the platforms.

Basically, Java is the right choice when your developers happen to be experienced in Java. However you still need to make platform specific builds to abstract the java-ness (e.g. user downloads an '.exe' rather than a .jar') and your users will be pissed if you deliver your 'webapp' as a jnlp.

It may be abuse, it may be a stupid patent, but it's not patent trolling. The point is that is a specific form of nastiness that describes company with literally *no* product but a patent portfolio and only makes money through litigation.

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.

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'.

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.

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).

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.

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.

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.

https://bugs.debian.org/cgi-bi...

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.

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.