Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?

Comment Re:We already had one (Score 3, Informative) 25

Yes, they're fictional, but it's a good start, since after all it proves that modern-day researchers weren't the first people to think of classifying planets by their habitability characteristics. Also, the simple "class [letter]" scheme is easy to remember and use; I sure hope they don't come up with some arcane, complicated system instead. Finally, they should definitely use "Class M" to refer to Earth-like planets simply to pay homage to Star Trek. Everyone and his brother knows what a "Class M" planet is, as long as they watched some Star Trek within the last 50 years.

It looks like you got your classes from Star Trek too, as seen here, but with some differences. I'm not sure where you got Class Q or I. The system probably does need a little revision though. Class H's "generally uninhabitable" doesn't tell you why. The Class P (see appendices) for icy planets is a good example. Class N for "sulphuric" really isn't sufficient; Venus is more like the Class Y "demon planet" except there's no dilithium-based biomimetic lifeforms, but the fact that Venus is so hot is important it needs to be classified that way. If a planet is too cold or too hot to live on, that's an important factor for humans. Same if there's no atmosphere. A planet (or moon) that's not too warm or hot but has no atmosphere can still be inhabited using domes or other sealed habitats, so that should be a class by itself. Mercury probably wouldn't fit there however, because it's much too hot. But it's hot in a different way than Venus, so they should have different classifications (hot because it's too close to the star, vs. hot because it has a thick atmosphere and runaway greenhouse effect). Finally, moons and planets should be classified together. The orbital path doesn't really matter (except insofar as it affects the climate/temperature). There could very well be Earth-like moons out there somewhere, so those should be Class M (like the moon in "Avatar").

So here's my proposal which borrows from ST:
Class M - Earth-like, small, rocky, oxygenated atmosphere, right temperature
Class D - small, rocky, little to no atmosphere, right temperature, inhabitable with sealed habitats (e.g. Mars)
Class J - gas giant (any size; this may be expanded later after we explore more star systems and decide we need to classify them further)
Class E - small, rocky, little to no atmosphere, too cold (e.g. Pluto)
Class F - small, rocky, little to no atmosphere, too hot (e.g. Mercury)
Class G - small, thick atmosphere, too hot (e.g. Venus)
Class A - very very small, not spherical (e.g. moons of Mars, captured asteroids)
Class B - very small, spherical but extremely low gravity (e.g. Sedna, Ceres, Pluto, dwarf planets in general)

I'm probably missing something here, perhaps planets with only liquid surfaces. I avoided calling Venus "Class N" because it sounds too much like "Class M".

Comment Re:Not surprising (Score 1) 315

Well, unless you count App Ops in Android 4.3 (until it was removed) and builds of CyanogenMod starting with 10.2.

Or any Android device with 4.3 or later with the Xposed framework and the AppOpsXposed module installed and active, at which point AppOps shows up in Settings just like it ought to.

Comment Re:Not surprising (Score 1) 315

And in my experience, apps don't seem to much care if you kill a flag or two. Perhaps because the ability to do so is not yet that common.

There are multiple reasons. Mostly two: you don't want to fail if the user is missing some hardware that the software can work without, and the app doesn't actually request the permission from the OS until it wants to use it, unless it's very poorly designed. So if you for example deny the microphone permission, the app will never even have to decide if it's upset about that unless it tries to grab some audio.

I forget what versions it appeared and disappeared, but Google did put this functionality into an older version of android, then removed it again. You can get it back on rooted devices by installing Xposed and installing AppOppsXposed. Many custom ROMs also have this functionality baked into the ROM so you don't need to mess with Xposed, but Xposed+App Settings+Gravitybox is very wonderful and you want it anyway, if you're not running CM especially. If you can't root your device, make better purchase decisions in the future.

Comment Re:Documentation is rarely valued as a contributio (Score 1) 390

Unfortunately, this shows why books are kinda obsolete for anything that's still under development. For things like awk, sed, grep, etc., they're great, because those things haven't changed much in ages. For a whole OS, not so much; they're all changing constantly. There is an e-book on git at git-scm.org, but being an e-book it gets updated, plus it seems like git has stabilized now.

I'm not so sure the cathedral model is really necessary for a competent and motivated tech writer however. As long as the tech writer can navigate git (using a GUI program like gitk or TortoiseGit or whatever), they can follow the development of the project and then update the documentation soon after changes are made, having the doc updates ready in time for major releases.

But for anything that's still under active development, the docs are always going to be going out-of-date unless someone keeps them up-to-date. This is true of any software project. You can't use a book about Windows Vista for Windows 10.

Comment Re:Documentation is rarely valued as a contributio (Score 1) 390

I can't speak for other people, but personally I do value documentation. Not that I want to spend all my time documenting someone else's work, but when I need to learn about something, documentation is invaluable. No, it isn't as fun as writing code, but that doesn't make it useless. If someone else wants to contribute to FOSS and isn't a coder, but can do tech writing, I for one would appreciate their contribution to documentation.

Just because a lot of stuff isn't documented well doesn't mean it should be this way. git is a bit of a special case: it does have documentation (there's lots of man pages for it), but the problem is that its UI is organically grown, it wasn't really designed with a consistent interface, and it shows (badly). It's very powerful but the interface isn't the greatest; I usually find myself googling for answers when using git, and winding up reading stuff on stackexchange. Good documentation only helps so much when you have a wacky UI.

Comment Re:Just (Score 1) 160

If the utility is going to charge me a grid-tie fee, make that fee the same as all of the subscribers. IE, any house with approximately the same service type (200A 240V Single Phase with Neutral) should have the same grid-tie fee as I as a solar user would have.

That sounds fair, but it actually isn't. Somebody who, at unpredictable intervals, will be feeding power into the grid requires a more expensive hookup than somebody who will only ever draw power from the grid.

A sine curve goes off to infinity, or at least the end of the blackboard. -- Prof. Steiner