Follow Slashdot blog updates by subscribing to our blog RSS feed


Forgot your password?
Note: You can take 10% off all Slashdot Deals with coupon code "slashdot10off." ×

Comment Re:Why would you want this? (Score 4, Insightful) 66

It's because they throw out a lot of POSIX features/requirements - e.g. nested directories, rename, links, durability/consistency guarantees. In other areas, such as permissions, they have their own POSIX-incompatible alternatives. These shortcuts do make implementation easier, allowing a stronger focus on pure scalability. The theory is that the combined complexity of POSIX semantics and dealing with high scale (including issues such as performance and fault handling) is just too much, and it becomes an either/or situation. As a member of the GlusterFS team, I strongly disagree. My colleagues, including those on the Ceph team, probably do as well. The semantics of object stores like S3 have been designed to make their own developers' lives easier, and to hell with the users.

Not all POSIX features are necessary. Some are outdated, poorly specified, or truly too cumbersome to live. On the other hand, the object-store feature set is *too* small. I've seen too many users start with an object store, then slowly reimplement much of what's missing themselves. The result is a horde of slow, buggy, incompatible implementations of functionality that should be natively provided by the underlying storage. That's a pretty lousy situation even before we start to talk about being able to share files/objects with any kind of sane semantics. You want to write a file on one machine, send a message to another machine, and be sure they'll read what you just wrote? Yeah, you can do that, but the techniques you'll have to use are the same ones that are already inside your distributed object store. Even if both their implementation and yours are done well, the duplication will be disastrous for both performance and fault handling. It would be *far* better to enhance object stores than to keep making those mistakes . . . or you could just deploy a distributed file system and use the appropriate subset of the functionality that's already built in.

A semantically-rich object store like Ceph's RADOS can be a wonderful thing, but the dumbed-down kind is a disgrace.

Comment Re:Why would you want this? (Score 3, Interesting) 66

That is very untrue. I'm on the GlusterFS team, and we've had users providing "POSIX style FS access in a cloud-like environment" for years. Amazon recently started doing the same with EFS, and there are others. It's sure not easy, I wouldn't say any of the alternatives have all of the isolation or ease of use that they should, but it's certainly possible.

Submission + - Apple's "Spring Forward" Event Debuts Apple Watch and More

samzenpus writes: There was a lot of news at Apple's Spring Forward keynote today. Here's a list of some of the most eye-catching announcements.
  • HBO Now standalone streaming service coming to Apple TV and iOS apps in early April for $14.99 a month.
  • Lowered price of Apple TV to $69.
  • Apple Pay accepted at up to 100,000 Coca-Cola machines by the end of the year.
  • ResearchKit Announced: Is open source and allows medical researchers to create apps, and use the iPhone as a diagnostic tool.
  • New MacBook: Lightest ever at 2 pounds, 13.1mm at its thickest point. 2304x1440 display, consumes 30% less energy. Fanless, powered with Intel's Core M processor. 802.11ac, Bluetooth 4.0. and 9 hours of web browsing battery life. Supports many protocols through one connector USB-C. Ships April 10, starting at $1,299.
  • iOS 8.2 is available today
  • Apple Watch: Accurate within 50ms of UTC. Read and delete email, built-in speaker and mic so you can receive calls. It tracks your movement and exercise. Use Apple Pay, play your music, use Siri and get any notification you get on iPhone today. 18 hour battery life in a typical day. Sport model starting at $349, stainless steel price: $549-$1049 for 38mm, 42mm is $599-$1099, and gold edition starting at $10k. Pre-orders begin April 10th, available April 24th.

Comment Interesting pattern (Score 5, Interesting) 192

Below the line are languages that are more popular on GitHub. Above the line are languages that are more popular on Sewer Overflow. There's a distinct difference. The "GH" languages tend to be systems languages (Go/Rust/D) and CS favorites (Haskell/OCaml/Erlang). The "SO" languages tend to be more lightweight and application-specific - Visual Basic, Matlab, ColdFusion. "Assembly" seems to be an outlier, but other than that the pattern seems pretty consistent. Conclusions about the audiences for the two sites are best left as an exercise for the reader.

Comment Why make up a conspiracy theory? (Score 1) 397

If you think weather forecasting is easy, let's see some of your forecasts. A forecast which has been substantially correct for New England and merely didn't extend as far south as had been expected only underscores the difficulty of the exercise. Occam's Razor suggests that no cause beyond "honest mistake" need be posited. I know some people like to take every opportunity to prattle on about government overreach, but you're *really* stretching that fabric too thin this time. Get a grip.

Comment Re:Kohn is attacking a strawman (Score 1) 249

So, from "this isn't to say that we should throw intelligence out" you conclude that they want to throw intelligence out? Truly, you have a dizzying intellect. I can see that you enjoy playing "devil's advocate" (to use the more polite term) but when you have to try so hard that you make yourself look ridiculous maybe it's time to find a new game.

Comment Kohn is attacking a strawman (Score 5, Insightful) 249

What Poropat, Duckworth, and others suggest is that multiple traits - including "grit" - contribute to success. He even provides evidence to back up that hardly-surprising conclusion. So how does Kohn respond? By immediately projecting a "one trait uber alles" mentality onto the grit proponents. To be even more clear, he's attributing to them exactly the idea they're trying to refute. Then he cherry-picks examples of excessive persistence leads to adverse outcomes, ignoring the issue of whether those outcomes would be likely to occur in people who had developed other traits such as curiosity and openness. In the end he only demonstrates further the problems with any single-trait theory of learning, supporting exactly the point he meant to oppose.

Maybe his parents or teachers should have helped Kohn develop some more of those other traits. Like honesty.

Comment Re:Guy is a moron (Score 4, Insightful) 358

I agree with the first part of your comment, and came here to say almost the same thing. The law of unintended consequences strikes again.

The second part makes you seem like a moron. Seriously, losing access to your e-toy for a minute or two is worth killing over? Get a grip.

Comment Ancient news (Score 2) 190

About five years ago, I was involved in the installation of a thousand-node cluster in Boulder. We knew *before we went in* that we needed to change our EDAC (memory error correction) code to account for the higher rate of bit-flips due to the altitude. Some of the people we were working with had been there when those same problems nearly caused a months-long delay in a larger installation at NCAR nearby. We ended up running into a more subtle problem involving lower air density, heat and voltage, but *this* problem was incredibly old news even then.

Comment Re:First game! (Score 1) 704

Good point. In fact, what made me think of mentioning Adventure is that I'm hacking on Adventure 2.5 (a.k.a. 550) to make it playable with my daughter. I've already added code to work around one build error, modified some of the game logic having to do with save/restore annoyances, and found one crash if you "say" something too long. The point is that all of this is happening in Linux, based on code that was written well before Linux even existed. Surely there's a lesson there. Thanks for clarifying it.

Comment First game! (Score 3, Insightful) 704

Adventure, a.k.a. Colossal Cave, by Crowther and Woods (extended by others).

This was many old-school programmers' first exposure to computers as entertainment. For example, both my wife and I recall playing it on TI SilentWriters (paper output plus an acoustic modem) when we were kids. Even more than Space Wars, which was written at least a year later and only ran on much less common hardware, this was the start of computer gaming.

Comment Re:coding style can get you fired (Score 1) 430

If one developer is that critical within your organization, you've got bigger issues than source code line width.

On most projects, there will be parts of the code that few understand. Yes, if that number is zero or one you have bigger problems, but trying to get it beyond two or three for every single piece is infeasible. Given how mobile people tend to be nowadays, and how variable their working hours across different time zones might be, it's quite common that the only reviewer available at a time of need (e.g. fixing a customer's problem in production) might be in a constrained environment. I guess it's not a problem if all you want is rubber-stamp reviews of simple code, but otherwise it's something you have to consider.

Think of the majority of developers that are sitting in an office environment.

Um, no. Having all of your developers in a single office all the time is increasingly uncommon, especially on open-source projects. Even fairly stodgy companies often have remote workers nowadays, all the way down to cutting-edge startups where practically nobody lives in the same city. Assuming such a majority is a bad basis for deciding policy.

I've seen this kind of thing kill code reviews. Instead of looking for logic problems or design flaws, you'll get that one guy being anal retentive about line width or ratio of one thing to something else.

Yes, I hate that kind of review myself, and I'll bet I've been subjected to about a dozen times more of them than you. However, conforming to a line-length limit is comparatively easy. Required scaffolding and forbidden constructs, function-length and even variable-naming conventions can all be much more of a pain. Part of teams being professional is respecting your colleagues and putting needs before whims. If you can't do that, or if staying within a length limit is so hard for you, then - to borrow your phrase - you have bigger problems.

Comment Re:coding style can get you fired (Score 3, Informative) 430

The only issue I have is with code diff utilities that don't work well with multi-monitor setups.

You should try to appreciate that not everyone shares your circumstance. Sometimes the most senior developers on a project might have to review code while on the road, e.g. visiting customers or presenting at conferences. Not too many laptops have multiple monitors, and you wouldn't want to carry one if it did. Some of the very latest have pretty decent resolution, but they cost a lot more and they have a very fine dot pitch so the number of characters doesn't scale up as much as the number of pixels. Under those circumstances, code that doesn't display well in a *side by side* diff on a single small-ish monitor is a more serious issue than the junior developer's fetish for super-long lines. Eighty columns might not be the absolute best width, but it's in the range that makes such diffs under such circumstances productive, and it's a width that a lot of people (and tools developed over the last few decades) can handle reliably.

Also, people who study reading have known for half a century that long lines are hard to scan accurately without a saccade leaving the reader's eyes on the previous or next line, which means that they're bad for readability even on wide monitors. There's a reason newspapers used to set type in columns instead of all the way across the page. You'll need a much better reason than personal aesthetics to do something that's bad for readability and a pain for other members of your team. Without such a reason - and I haven't seen any, anywhere in this thread - that's just selfish and immature.

Any sufficiently advanced bug is indistinguishable from a feature. -- Rich Kulawiec