Follow Slashdot stories on Twitter


Forgot your password?
DEAL: For $25 - Add A Second Phone Number To Your Smartphone for life! Use promo code SLASHDOT25. Also, Slashdot's Facebook page has a chat bot now. Message it for stories and more. Check out the new SourceForge HTML5 Internet speed test! ×

Comment Re: MapReduce is great (Score 1) 150

Removable media (e.g. tape and WORM optical disk) libraries were typical for petabyte+ storage arrays back in the late 90s. I remember the Subaru telescope facility in Hawaii had a petabyte storage facility which was primarily an automated tape library (plus a large section of wall occupied by a physically massive ~40gb RAM array) when I very briefly interned* there in the late 90s.

That was large, but not uniquely or ridiculously large. My WAG is that, globally, there were probably on the order of 1k installations of similar or greater magnitude at the time. Certainly some of the DOD projects at LLNL would easily have been at the scale your parent poster claims.

*I.e. assisted with workstation builds & linux installs.

Comment Re:This is ridiculous... (Score 1) 337

What you say is perhaps the way it should be, but not precisely true either. The reality is that the DOJ has an absolutely incredible degree of leeway and discretion in terms of its enforcement agenda and priorities.

This is nothing nefarious, just the inevitable outcome of the confluence of the following factors:

  • The sheer number of laws on the books
  • The overwhelming number of potential law enforcement actions possible as a result of the above
  • The limited resources of the DOJ
  • The reasonable expectation that the DOJ exercise judgment in enforcement actions (e.g. murder cases are higher priority than shoplifting cases, which might not even be pursued at all) and not use a totally unbiased but stupid approach like a strictly ordered queue ordered by filing date

Note that the DOJ having discretion is not the same as a single, all-seeing mastermind at the DOJ directing traffic on all possible investigations and enforcement actions. In many cases it is the emergent outcome of policies developed to translate law into rules, discretion exercised by bureaucrats at various points in the process, etc. that ultimately decides the path of a case.

It might also be the result of purely political policy decisions by the members of the executive branch or others with the ability to influence enforcement policy. Many people are only now beginning to understand the extent and magnitude of this factor as you see the absolutely stark contrast between the Obama administration's policies and those of the Trump administration. Policy decisions by the executive branch can decide whether or not you get deported, whether or not states condoning recreational marijuana sales get busted by the FBI/DEA/ATF etc., and how aggressively (if at all) DOJ pursues certain types of potential violations (e.g. ADA & IDEA violations) through very direct and transparent means like executive orders, or more indirectly through methods like withholding funding or authorizations required to staff an enforcement division.

"What the DOJ cares about is irrelevant" might be the way it should work in theory, but not how it works in practice. There was nothing inevitable about the DOJ handling the case the way it did (indeed, nothing inevitable about them handling the case at all--if not outright de-prioritizing the case, many of these issues are resolved differently based on the highly variable inclination and ability of DOJ personnel to convince parties to go through ADR/mediation rather than issuing an order or proceeding through litigation). To be clear, I'm not necessarily saying the DOJ mishandled the issue or made misjudgments, I'm just pointing out that they did in fact exercise judgment (it's just the way these things work in practice).

Comment Re:Why? (Score 2) 238

It seems like you're assuming that the sphere is pumped full of air when the water is drained out, but that is not a necessity. In fact, doing so would needlessly complicate the design significantly as it is scaled to greater depths while simultaneously compromising its power generation potential by reducing the pressure differential between the interior and exterior of the sphere.

What your're looking at is more like an implosion of a ~14,000m^3 vacuum chamber which might not even be obviously noticeable from the surface when the sphere is placed at greater depths.

Comment Re:Why? (Score 1) 55

No, there really isn't any excuse for using raw inline SQL given the existence and ubiquity of parameterized query APIs. They provide all of the flexibility of raw SQL but with guaranteed proper escaping of value text and thus no SQL injection vulnerability (bugs in the API implementation notwithstanding).

Submission + - A blast from the past! Disney/Lucasarts release X-Wing and Tie Fighter!

An anonymous reader writes: Time for a trip down memory lane for you old school gamers, GOG has posted digital downloads at $10 a pop for the updated versions of X-Wing and Tie Fighter for Windows with hints of more to come from the vaults at Lucasarts.

Submission + - Indie Developer Crashes PAX East With an Oculus Rift and Draws Huge Crowds (

An anonymous reader writes: [James thought] he'd try his luck at some guerilla PR tactics and crash PAX East with his trusty Oculus Rift and demo rig in tow. After many laps of the PAX East Show floor, James was about ready to give up and go home, but on his final round he spotted a demo station with one lone occupant and his Oculus Rift. This was his chance.

Comment Re:It's a Great Learning Experience (Score 1) 226

I suspect there's a bit of a definition issue at play here (with all fault apparently being on my end, given some of the other comments in this discussion). In my mind, DevOps roles are such only if the "Dev" and "Ops" parts are connected--I.e., you manage operations for the software that you've developed. I agree that there are rapidly diminishing or negative returns otherwise. E.g., if you write some Nodejs web services on Monday and troubleshoot MS Exchange/ActiveDirectory integration issues on Tuesday, there isn't much benefit. In that case, however, I'd argue that you don't have a DevOps role, you just have 2 different unrelated roles (which, as I stated, is apparently a definition issue on my part).

The only part that I would argue with is..

The difference is between developers knowing the operations side and being the operations side.

You cannot, in my opinion, "know" the operations side if you have never actually been the operations side. The real question is whether knowing the operations side is worth the effort of being the operations side (at least for a while). In my experience, the answer is unequivocally "yes" (but again, with the caveat that you are the operations side only for the software that you develop, and not for, e.g., rolling out the latest Windows service pack to all users at your location).

I should also clarify that my experience has only been with internal development. The demographic differences with respect to external-facing applications (i.e., user/developer ratios on the order of possibly millions to 1 vs. 10s or 100s to 1), among other things, would necessarily limit the ability of developers to participate in operations.

As you've noted, having to run operations to the exclusion of all development activity would bore you to tears. What that has done is forced me to consider--to a degree and precision that would never have occurred to me previously--how the design and architecture of a proposed solution impacts deployment and operations. Because I did not want to spend all my time supporting the system I mentioned in my previous post, I designed it such that it required about all of 30 minutes every other month to administer, and was easy as hell to troubleshoot in production. This meant a much more complex design, and more difficulty in implementation, but saved me a ton of time on net balance such that I could still spend the vast majority of my time doing more interesting stuff.

If deploying and administering the software that you've developed becomes your full-time occupation to the exclusion of all other activity, then either:

  1. You do not actually understand deployment and administration in the relevant environment(s), and are therefore horribly inefficient at it (and would benefit greatly from learning).
  2. Your design made it very difficult/time-consuming to deploy and/or administer. This is almost an inevitable outcome if the above is true, but can also occur if the developer has a "not my job/problem" attitude when it comes to deployment and administration, or can be a straight-up deliberate trade-off based on available resources.
  3. Both of the above. Or...
  4. You are working at a scale or in a domain for which deployment and administration is an inherently difficult problem independent of solution design (though paradoxically in this case it is usually even more important for the developer to understand Ops, because while there may be little they can do to make the hard problem easier, there are lots of ways they can inadvertently make the hard problem impossible).

Comment It's a Great Learning Experience (Score 4, Interesting) 226

I essentially have this kind of role within my organization. I design, develop, deploy, and support small to mid-tier systems (e.g., the planning system for a $XXXmio/yr global department, with 300+ direct users) while being one of my own customers, as I am actually a business planner (by role) as opposed to developer. I develop systems as a way to do my "day job" much more effectively. Typical tech stack would be Excel UIs, PostgreSQL data store, and whatever else I need in the middle (e.g., nodejs, tomcat, redis, whatever).

What I've found is that, in general, doing the right thing the "right way" is not worth the cost compared to doing the right thing the "wrong way". By definition, in either scenario, the right things is getting done. What most pure developers utterly fail to understand is that in trying to do the former, there is an overwhelming tendency to do the wrong thing the right way instead.

This is because, as Fred Brooks pointed out long ago--and as the "lean startup" movement is re-discovering today--for any non-trivial novel problem you cannot know in advance what the "right thing" is until you've actually tried to implement a solution. Brooks stated this understanding as the need to throw away the first try, and the lean startup movement is essentially defined by a corollary--you have to figure out how to try cheaply enough that you can afford to throw it away and try again (and again, and again if necessary), while progressively elaborating a robust definition of what the "right thing" looks like by using those iterations as experiments to test hypotheses about what the "right thing" is. Doing things the "right way" usually costs so much in time if not capital that you simply can't afford to throw away the first try and start over, or you cannot complete enough iterations to learn enough about the problem.

Now, I'm not saying that you should be totally ignorant of software engineering best practices, design patterns, etc. What I am saying is that there is a limit to how effective you can be in reality if you live purely within the development silo. Having a "DevOps" role (granted, self-imposed in my case) has been one of the best things that's ever happened to me as far as making me a better developer, right up there with the standard oldies like writing your own recursive descent parser and compiler.

In short, it is commonly-accepted wisdom among programmers (for good reason!) that you are more effective if you actually understand the technology stack down to the bare metal or as close to it as you can manage (even if only in abstract-but-helpfully-illustrative examples like Knuth's MMIX VM), and that this understanding can only be gained via practice. It should be obvious that the same is true in the other conceptual direction through deployment and end use.

Comment Re:How long would that last... (Score 2) 353

You can basically interpret it as "I acknowledge your communication". It is meant to convey that they are, in fact, paying attention and wish to communicate that fact, but the acknowledgement is specifically devoid of any communication regarding the interpretation or judgment of the content communicated.

Comment Re:Yeah, like the present school system is working (Score 2) 715

When it comes time for admission and staying in, a student in the top 10% of a US high school just does not have the ability to compete with his/her counterparts who come from China and India [1]. It is like someone wheelchair bound competing in a 100 yard dash against 10 Usain Bolt clones for a single spot.

What you are seeing is the effect of the top 10% of a country with 300M citizens competing agains the top 0.01% of countries with 1B+ citizens each.

Given that educational opportunity in other countries is also subject to extreme selectivity, those 0.01% have also had the benefit of superior education not just through the system provided, but also due to the peer environment. A genius in a school full of geniuses must learn to work hard to succeed as opposed to being able to coast on the momentum of inherent advantage. The benefit of developing a good work ethic manifests itself in college where even a genius has to apply themselves consistently (if not strenuously) in order to master the material being presented.

Comment Re:Why couldn't he say this 10 years ago? (Score 1) 341

Maybe if someone actually spoke the truth while in office the problems plaguing our government would have a better chance of being addressed.

No, but this is probably difficult to understand until you've held or are qualified to hold a position of significant accountability and independent authority. At the level of executive leadership, you have to be cognizant of the consequences--especially with respect to your responsibilities.

Essentially, the problem in this case boils down to the fact that speaking candidly as he is doing now would have destroyed his ability to be an effective Secretary of Defense, as the little cooperation he was getting from Congress and the Whitehouse would have evaporated in an instant. It therefore would have been an irresponsible thing to do while he held that position.

The logic goes something like this:

  • - If I am going to prosecute a PR battle with powerful but corrupt/petty/incompetent politicians and bureaucrats, it will do no good unless I win
  • - In order to win a PR battle with professional popularity contest winners and influence brokers, I will need to devote all of my energy to the effort. Failure is still probable.
  • - Even if I win, is the resulting good still worth the opportunity cost related to the list of tasks T that I have allowed to lapse in the meantime? (hint: the answer is 'no' when T == 'stuff the US Secretary of Defense is supposed to be doing').

The responsible thing to do is to pour your energy into fulfilling your responsibilities. If you do not feel that you can fulfill them adequately, resign (after some due dilligence to ensure sufficient continuity in the organization). Wait a while before commenting on your past position and its challenges, as doing so immediately upon resignation is likely to poison the well for your successor. These are the actions of someone focused on doing the best thing to fulfill the responsibilities of the role--up to and including self-removal therefrom if the logical conclusion is that they are not able to effectively do the job.

If you feel that the role of critic is more important than the role you were given, you should not have accepted it in the first place and instead applied to become a journalist/commentator.

Comment Re:Of course not. (Score 1) 227

The example you gave, if true, is a classic demonstration that IT management does not understand their business, not the other way around.

First, while you may want to approach a person directly to give them a friendly heads-up as a first step, the basic thing IT management is supposed to understand is that a user having weak passwords is not so much a risk to that user but a risk to the business. If a user ignores your friendly heads-up, or the problem is more widespread than 1 person, the next step is to go to the person responsible for that part of the business. Now, you don't have to be a douche and call out the specific individual(s) in question, but you then tell that person that there is a systemic risk to their operation because X% of users (or alternatively, a few users with extensive access rights to critical systems) have weak passwords that all appear near the top of /-/@xX0r brute force password dictionaries.

The key thing that even moderately competent managers (IT or otherwise) understand in these kinds of situations is that you have to put the decision (and relevant information) in squarely in the hands of the person accountable and responsible for the issue. In this case the issue is not that someone has a weak password that might result in someone messing up their My Documents folder, it is that weak passwords are a risk to the business. If a bank comptroller's password is 'password', that is not a problem-waiting-to-happen for the comptroller, it's a ticking timebomb for the bank.

In your example, you do not put the decision to act (or not act) in the hands of the account owner, but in the hands of the account owner's business unit head.

Security and IT issues in general tend to get short shrift in many business (at least in my personal experience) not so much because non-IT/non-technical managers are stupid, but because the IT managers lack even basic competence relative to the second half of their title.

Comment Re:TDD (Score 1) 156

Your parent's statement is not an oxymoron.

If every single print driver has components running in both ring 0 and userspace, but the preponderance of components (by number or 'size') of every single print driver is in userspace, then it is more precise to say that "all print drivers are mostly in userspace" as opposed to "printer drivers are mostly in userspace". The latter is semantically a superset of the former, as it could either mean the same thing, or also describe a situation where some printer drivers are completely implemented in ring 0, but the majority are completely or mostly implemented in userspace such that the preponderance of the set of all printer driver implementations resides in userspace.

In other words, your parent's statement is more precise about not only the aggregate population of printer drivers, but the distribution within the population. Whether that statement is actually correct or even the real intent of your parent poster's statement is another question :).

Slashdot Top Deals

Like punning, programming is a play on words.