Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror

Comment: Re:The bases have to be built from local material (Score 1) 46

Wait, scratch that. The majority of the dwellings will need to be underground to avoid the radiation. Instead of a 3D printer, take a tunnel boring machine.

You can't make everything you need out of holes. Your tunnels will need doors, partitions, tables, etc., etc. No IKEA on Mars and the shipping charges are horrendous. There are lots of things besides main structural walls to be made.

Comment: Re:Cost bigger issue than sonic boom (Score 1) 72

Thanks for all your calculations, but you entirely neglect auditory acoustic response issues, or the fact this energy is coming exclusively in rapid rise impulses.

There is more direct information in this readily available. We read here that the
"Concorde's sonic boom noise level was 105 PLdB. The PLdB that researchers believe will be acceptable for unrestricted supersonic flight over land is 75, but NASA wants to eventually beat that and reach 70 PLdB."
The measure PLdB is "perceived level of decibels" which takes into the account that impulsive, rapid rise sounds appear louder to humans. A 105 dB sound is a very loud sound to anybody. There would be hundreds, perhaps even thousands, of supersonic flights coast-to-coast a day if this became commercial. If you were under a common flight corridor, you might hear one of these every few minutes all day long.

The NASA article discusses though the fact that aircraft design can lessen sonic booms, and that is real key to making this a viable transcontinental technology.

But where we really need supersonic flight is on trans-Pacific flights! Where are the hypersonic trans-Pacific airliner projects these days?

Comment: Re:What's with all these "kinds" of music? (Score 1) 360

by careysub (#49697303) Attached to: What Happens To Our Musical Taste As We Age?

There are exactly two different kinds of music - good music and bad music. What makes music good or bad is left up to the individual - everybody has different opinions. I'm 62, from a small town in Alabama, a child in the fifties, high school in the late sixties, college in the early seventies, and guess what? I like it all! From classical to the latest, there's good to be found (and a LOT of crap). There's even good and bad music from the same artist, e.g. Eric Clapton early was great, but kinda lame later. I usually listen to music played randomly from my collection. You could hear an old bluegrass song followed by Nirvana followed by Bach followed by a gospel song followed by a Disney tune. The only thing all the songs have in common is that they're only the good ones. On the road I listen to XM. The presets are Symphony Hall, Met opera, Lithium, Classic Rewind, Bluegrass Junction, and BB King's Bluesville.

Amen to this! I like everything - if it is good. I enjoy discovering new styles, genres, bands. I have been around awhile, but I was one of Pentatonix's first fans for example. Went to one of their concerts a few months back - Cello/beatboxing was showcased and it was cool! Check out Mattisyahu: his Hassidic/Reggae/Rap fusion is brilliant. Here's a tip - listen to an unfamiliar style/genre more than once. I listen to music from all over the world. It takes time to appreciate the nuances that each style/genre brings. (Bluegrass is one of America's greatest contributions to music.)

Comment: Re:A Lot of Software Defies Easy Explanation (Score 1) 244

by careysub (#49695265) Attached to: RTFM? How To Write a Manual Worth Reading

I am a big proponent of agile methods (see the agile thread today), but here I disagree. A UI is part of the system architecture, and architecture fundamentals do need to be defined early in development (but then refined and evolved as development proceeds). Agile is definitely not "making stuff up as you go along".

Comment: Re:You cannot know *WHO* is voting (Score 0) 258

by careysub (#49691225) Attached to: Online Voting Should Be Verifiable -- But It's a Hard Problem

... really I have no issue with mandatory voter ID -- you just need to severely over-engineer the solution to ensure it's not a burden on those in society with the least time/money/options/eduction.

And the fact that these voted ID laws never include proactive provisions to get IDs into the hands of all voters for free reveals their true intent quite clearly. Heck, Ohio is trying to enact a poll tax (banned explicitly by the Constitution, 24th Amendment) by requiring a voter ID card that you must pay for.

Comment: Re:A Lot of Software Defies Easy Explanation (Score 1) 244

by careysub (#49691047) Attached to: RTFM? How To Write a Manual Worth Reading

I actually agree with this. The documentation does need to evolve with the implementation, and if you don't, it is as you say. But having a clear concept about how it is to be used, and working out a coherent description of using it is a very strong design tool to make a usable, understandable system.

Comment: Certainly Not (Score 3, Insightful) 507

by careysub (#49690777) Attached to: Is Agile Development a Failing Concept?

Iterative, incremental development - the core of agile - has been around at least since Barry Boehm described the "spiral model" of development in 1986, and has been successfully used for nigh upon 30 years since under various monickers (and I'll bet there were practitioners before Boehm's paper).

"Agile" has matured and developed a lot of inter-related supporting practices and tools that have made it increasingly powerful and easy to implement. Continuous integration, test-driven development, use of "stories" as a tool for requirements definition, you cannot tell me these techniques and tools are not successful.

I have personally seen the development practices of a company dramatically transformed for the better by having an agile trainer brought in and training the entire staff, including managers, and instituting formal agile practices. It is great when a junior developer can tell the VP of marketing to take a hike because his request has not been submitted through the grooming and priority assignment process.

This one experience gives me complete confidence that people mocking agile simply do not know what they are talking about.

One problem agile does have is with zealots who don't understand that this is, and has to be, a collection of related practices that must be tailored to the needs of the environment, not a one-size-fits-all, all-or-nothing thing. Another problem is thinking that "form" is what is important, not "what is happening".

For example: holding stand-ups is not agile. It is a common, useful tool to use in an agile environment. If your team is coordinating with informal sessions as needed, Skype, chat tools, and an updated Wiki in real time, and the managers are keeping in the loop using these tools, then maybe a stand-up is a waste of time for you. I think most teams benefit, but design and planning is not part of a stand-up, other meetings are needed for these.

There can be long-term planning that does not follow the agile model, and can be described as water-fall, and this has its place too. But I think the only really successful development practices are variants of an "agile" type process.

Comment: A Lot of Software Defies Easy Explanation (Score 2) 244

by careysub (#49690405) Attached to: RTFM? How To Write a Manual Worth Reading

And not because it has to be that way. The software is just poorly designed.

In an ideal world, user documentation would be written before the software so that an understandable, consistent, UI would exist. This sometimes happens, but even then, the implementation may not match the documentation (yes, I have seen this more than once).

Design principles like: simple things (and common tasks, even if not exactly simple) should be simple to do; the same technique should work in all contexts; etc. are often ignored in OS projects.

I have come to despair in trying to find a nice open source (Linux) object-drawing program that is intuitive (and thus easy to learn), has consistent behavior, and allows the quick creation of clean basic diagrams, and maybe has an additional level of finer controls for more precise work. The original Macintosh had this back in the 1980s with MacDraw, and the even more awesome MacDraw II. Complete novices could take the program and discover how to make good looking "boxologies" in minutes just by playing with the tools. Maybe such programs are still available on the Mac platform (I haven't had one in years), but no OS object drawing or 2D CAD program on Linux seems able to grasp what one of the first such pieces of software on the market was able to accomplish.

(Another really annoying thing to find in user documentation is self-praise about the product and accompanying documentation: making promises about how great the product is, and how wonderful the documentation you are looking at is, that are rarely kept.)

Comment: Re:Manual? We Don't Need No Stinkin Manual (Score 1) 244

by careysub (#49690159) Attached to: RTFM? How To Write a Manual Worth Reading

Videos have their place, I grant. Especially when it comes to manipulating some object (could be a graphical object on a screen), where a verbal description just cannot compete.

But I hate "video documentation" with an undying passion. They have an extremely so rate of information transfer, typically very low information density (see how little text is in a 5 minute video script), cannot be scanned at all, require you to have an audible audio hook-up, cannot be copied for notes,... I'm just getting started here, but you get the picture. I can literally take in information 10 times faster in printed form, and locate relevant content even faster than that.

If video documentation is available as optional back-up, great! But if that is the only documentation, I will not use whatever-the-heck-it-is, I'll find something else.

Comment: Re:Rival? (Score 3, Interesting) 100

by careysub (#49685951) Attached to: Is Big Data Leaving Hadoop Behind?

They need to refer the the pieces of hadoop. HDFS is the storage piece and many things can interface to it, it isn't great but is often good enough especially if you just have a couple local disks per node. YARN is the scheduler piece, it is mostly awful performance-wise but is fairly easy to use...long run it'll lose to something like mesos I think.

That's a good call. With Cloudera and HortonWorks both adding new components to the Hadoop stack it has exploded in the number of components in the last a year or two, and that can be a bad thing. The complexity of the whole ecosystem is getting horrendous, with a typical configuration file doubling from 250 or so to 500 configuration items, which are almost all undocumented (unless you read the code - which scarcely qualifies as "documented") in the last year. For a practical deployment you are pretty much forced to use a commercial stack to get something up and running in a manageable fashion. And then there is the fact that the HDFS foundation is showing its age.

MR is the map reduce piece that everyone thinks of when you say hadoop. Almost everything will run quicker in spark(still using a map/reduce methodology) than hadoop MR.

Spark on Mesos is looking mighty awesome.

As a side note, I don't know anyone who still writes MR jobs directly, they are all doing pig or hiveql.

MapReduce is still viable for stable production jobs, but not in a dynamic requirements environment.

Although HiveQL is alive and kicking, the complete replacement of Hive Server with Hive Server 2, while possibly an improvement in usability overall (I am not convinced), it trashes your skill investment in the (now) obsolete Hive stack component. Maybe I am just grousing, but I start having reservations about technology planning in the data center when a key stack component changes so much it a relatively short period of time

The world is no nursery. - Sigmund Freud

Working...