KDevelop is starting to get there as well. It's still a bit buggy and needs some usability improvements (such as more automatic ctags stuff), but it's made quite a bit of progress and keeps getting better. I personally quite like the feature that gives each local variable its own tint (saturation can be adjusted in the config, mine's at ~10%); It takes a few hours to get used to and therefore not be a distraction, but once comfortable, the color coding makes visually scanning code easier to track. It's not quite up to Qt Creator level, yet, but it's something to keep an eye on.

As a Gentoo user who likes to cut out bloat, I HATE systemd, and now udev. udev now has networkmanager, systemd, and udev all as part of the same project, now. This huge bloat now makes it so that you can't even boot without an initramdisk (something I don't use) if you mount /usr on a different partition (which I do, because my /usr lives on an ssd). Not to mention, networkmanager uses a binary format for config. It's especially bad for embedded systems. I really don't want anything remotely like a Registry in linux. udev just keeps growing. Things like hotplug were perfectly fine as separate services. There's no reason to make everything monolithic, and is very contrary to Unix design philosophy.

If anything, I'd like to see things moving the direction of plan9. For example: wayland. A great way to make it very unix-y would be to make a virtual filesystem to handle creating windows in the style of plan9's /net. Have a command/syscall mkopengl, which would create /dev/opengl/{context,control,input,monitor,fb,data/}. context and control would have things like the window location and size. Updating those would just mean writing to those files. OpenGL instructions would be written to input. Reading from monitor would stream OpenGL commands written to that context. Reading from fb would grab the fully rendered frames (just cat into a file/encode from to record). Finally, data could have file descriptors to textures in video memory. Not only would a setup like this be powerful in terms of being able to chain programs together, but network transparency would simply be a matter of union mounting the remote /dev/opengl on top of the local /dev/opengl (the way NAT, etc works on plan9), or cat-ing from monitor into a local input "file".

fdupes is in Cygwin. No need for a livecd or vm. Cygwin can handle ntfs hardlinks well, too (I used a python/sh script in cygwin just a few weeks ago to hard link a bunch of photographs into a series of dvd-sized folders).

Also, in the future, I recommend using rsync to back up files (either remotely or to another directory). Rsync can do incremental backups using deltas (a binary version of diffs), which saves a ton of space. Rsync also works well in cygwin, and there are cron daemons available that will install themselves as windows services for automatic backup.

Indeed, and it's not exactly hard for someone to do the opposite and significantly reduce their own dna output if they were trying to frame someone. The semiconductor industry has been improving techniques to keep the rate of human contamination from technicians/researchers down in their clean rooms for decades, and a couple orders of magnitude difference is considered basic.

Only our lowest courts use juries. Panels of experts (multiple judges) has generally worked quite well in higher courts. Stuff like this and the Apple vs Samsung case make me wonder how great of an idea trial by jury really is. Sure, it's better than trial by fire or combat, but we have a representative democracy precisely because the average person lacks the time and/or training to comprehend the framework they are trying to make decisions from. There are so many things wrong with our criminal justice system.

Plus, if they had any idea as to how science works, they would know that one datum doesn't constitute reliable evidence at all. Even finding the same DNA in multiple locations doesn't rule out systematic contamination. Multiple types of evidence are needed to confirm causation with anything. It scares me that people's entire lives can depend on methods that would get any scientist laughed out of the room.

The physical damage of a dirty bomb is small, but the psychological damage has always been way higher with terrorist attacks than the actual physical loss. I'm well aware that dirty bombs basically just do as much damage as the conventional explosives used in them, but judging by how some people I've met reacted on the west coast of the US to negligible amounts of radioactive iodine from Fukushima, the psychological aspect could cause us to significantly harm ourselves with more useless wars.

Well, the best way would be to get the spent fuel back, and check the amounts. U-238 could be put near the reacting material like with neutron activation testing, but I don't believe that any remotely usable P-239 could be recovered that way (hence why reactors that produce plutonium have to be specially designed). It might be possible (I'm not an expert) to produce dirty bombs by heavily neutron activating a ton of stuff, but a dirty bomb is a far cry from a nuke, and it would be a very slow process. The main problem would be finding a place to keep the spent fuel, as nobody wants to have to keep the stuff.

No. That's not how it works. That is totally incorrect.

"Shor's algorithm will produce a nontrivial factor of n with probability >= 1-(1/2)^(k-1) where k is the number of distinct odd prime factors of n."
Number Theory for Computing By Song Y. Yan

Public key cryptography that is susceptible to Shor's algorithm specifically choose to use two prime numbers, so the probability of success is always theoretically 50%. Verifying the result is trivial. All that's needed is to feed the result into an oracle (easiest to do classically) to see if the result is valid, and loop until the oracle says "true". The loop can stop any time a correct answer is found; which one is correct is not based on statistics but an easy P complexity check. There are many quantum algorithms that only work a certain percentage of the time, and it isn't a problem.

So, then, show up in a convoy of cat-filled trucks. That should do the trick.

And now, there's a push from the udev group to merge /usr into /. For years, /bin and /lib had everything needed to boot to the first stage, but now, udev is starting to drag in dependencies from /usr in the preliminary boot stage. This means that in order to have a separate /usr partition (such as on an ssd), it will be mandatory to also maintain an initramfs with all the files required for the particular udev configuration. An initramfs shouldn't be required for a basic boot. If a feature isn't mandatory to boot, put it later in the boot process. udev and systemd also merged, so this behemoth could become even more restrictive, especially due to the fact that NetworkManager doesn't save its data in a human readable format; what's next, a Linux version of the Registry? This is the opposite direction to how I want to see Linux going. The Unix philosophy of simple parts that can be chained together is getting completely trashed. If anything, I would like to see some of the ideas from (lan9 implement, like /net, where network connections are done by talking to control files, eg. /net/tcp/2/{ctl,data,listen,local,remote,status}. Fancy new features are very nice, but they should always be optional so as to not be restricting.

What's wrong with using 0.0.0.0? It's defined in ipv4 to designate an invalid IP, and unlike 127.0.0.0/8 addresses, it won't hit local web servers or have to wait to time out.

Perhaps some corporation will throw money into making kde-plasma a stable shell to use on Windows. It fully replaces explorer.exe rather than being some sort of dll hack, and allows for a powerful customizable shell and program compatibility. The cost of getting plasma running perfectly in a windows environment could be a lot less than major retraining of huge amounts of employees (theme things to feel like Win7), especially if Microsoft decides to switch things up again in Win9.

It's very hard to measure the efficiency of theoretical science. In rare cases, a discovery can revolutionize the world. In some instances, discoveries can create new products. In others, there may be no practical value to the discovery, merely a stepping stone to something greater or merely a better grasp of the universe. Many things fail to produce any benefit except for knowing what probably doesn't work. All of these things are advancements, but there is a huge amount of variability.

This could still easily be written as a filesystem, or more precisely, two. First, write a filesystem that accesses the online storage. Secondly, get a good union mounting FS. Make a union mount between the directory you want things to be in and the online storage. Configure the union mount to synchronize the bottom layer with the top layer. The union mounting would be useful for other things as well, such as automatically syncing a flash drive with a folder or caching network drive data. A read only base layer with a rw top layer allows for the base system image + configuration image for netboot. Much of this is already working in Linux, though not necessarily feature complete, yet.

Also, does the fact that many phones support voice commands mean that it should be suspected that the microphone is always on? If all the cell providers decide they get remote access to your phone, does that enable all phones to be used as warrant-less bugs? Cell phones aren't exactly voluntary these days. "Required by our civilization" should be the benchmark, not the Amish.