Obviously ideally you would be using all your kit at 95% capacity all the time
Yep, if your developers aren't working 24 hours a day, you need to outsource half of them to the other side of the world. That way you get your money's worth out of the development servers.
Is it obvious to "a person having ordinary skill in the art?" Some federal judges consider the guy who goes around replacing network cables to be a typical "person having ordinary skill" in the "art" of "doing stuff with computers." That means anyone who has a CS degree or can write a single line of code is waaaaay too smart to be included in the nonobviousness test, and you can patent any damn thing you want as long as it's useful and involves programming. The patent holds until someone produces evidence of prior art.
I have been setting up a couple of 8-drive RAID-5 arrays with these drives for some customers, and I also found out that 3.AAE drives performed much better that 3.AAK.
I have two questions that are going to sound a bit trollish, so I apologize in advance, but you sound like the right person to ask. I really wouldn't give a damn about this except that I buy a hard drive now and then and don't like to buy from companies that jerk people around.
According to the article, the AAK drives perform a bit better than the AAE drives on the carefully engineered server-oriented benchmarks, the AAK drives perform significantly worse on very simplistic benchmarks (which are somewhat meaningful since they happen to measure things that cause some desktop users to sit and wait,) and on workstation-oriented benchmarks it's a wash. So, there's actually a significant chunk of users who would prefer the AAK drives over the AAE drives and another chunk who wouldn't care much about the difference, yet server-oriented people aren't posting here complaining that they might accidentally buy an AAE drive and get 4% less performance or whatever the difference is. First question: Is this just a case of people putting too much stock in the performance measurements that they themselves can easily perform, as opposed to the complicated server or workstation benchmarks that probably reflect real usage better? I understand that the differences in the simplistic benchmarks are larger, but you would expect real performance to be more like the complicated benchmarks than the simple ones. (After all, how often do people copy large files locally?)
Second, since it hasn't been mentioned, I assume that Seagate doesn't specify the performance of this model well enough that the AAK drives can be called "out of spec." Also, each drive is evidently superior at some tasks, so the big deal is that parts with different performance characteristics are being sold under the same product number. Forgive me if this sounds cynical, but isn't this completely normal with consumer-grade, loosely specified hardware?
You've got to have the machines off-network, which pretty much implies that your scenario is for a "road warrior" going into client premises.
Not necessarily -- they could be servers or appliances sitting on client sites. For instance, if you provide IT services for other businesses, you might install network appliances at their business sites. The logs might be uploaded during off-peak hours, or they might simply sit on the machine until they get deleted or until you decide you need to look at them to investigate a network failure or intrusion. These logs may contain information that can be used to plan attacks, such as network configuration info and package versions, so it's nice if they can't be viewed even by someone who roots the box. (You may want to keep the information secret from your customers, so physical access is a concern, too.)
Or the computer might be located in a hospital, where it controls a medical device or gathers data from medical devices. The IT staff who do maintenance and monitoring on those systems might not be authorized to view patient information, so anything related to patient information might need to be dumped into a special encrypted log so that it can only be viewed by a proper authority, not just by anyone who has root privileges on the device. It doesn't protect you against an IT guy who has the skill to tamper with the binary that logs the data, but there aren't very many of those. It does protect you against lots of scenarios that a non-encrypted log file would invite -- for instance, an IT guy thinking, "I'll just take a quick look in that log that I'm not supposed to look at. It won't hurt anybody and will save a ton of time. I'll just grep out what I need and then look at it in emacs.... Oh, crap, this system doesn't have emacs installed, but I can copy the data to a machine that has emacs." It might even help legally if you can't view the log without doing something sophisticated and outrageously illegal (e.g., patching an executable in a medical device) as opposed to something that can be done in a simple and innocent-seeming way (e.g., an IT guy grepping through a log file.)
Are you mixing between encoding and encrypting? If the (bespoke) application stores it's logs in it's own format (as opposed to plain text), and the end user in the field simply doesn't have the modules of the program that can convert that code ("Friday"=0xFE ; "bananas"=0xFD ; "Location 48, Port Harcourt"=0xFC) back into a human readable form, then there is a considerable reverse-engineering problem facing the hacker, but it's not a decrypting problem, it's a decoding problem.
I'm actually talking about asymmetric encryption, where a program has the information necessary to encrypt data but can't decrypt the data after it encrypts it. A simple example is when you PGP a document using someone else's public key. You can't decrypt the resulting file, unless you also encrypt it using your own key. (It's kind of embarrassing when you have to call somebody and ask them what was in the document you sent them last month, because you forgot to use your own key as well. Not that that ever happened to me, of course....)
Application-level encryption might be easier than system-level encryption, but you haven't convinced me that it's the right thing to do.
Absolutely; there aren't very many scenarios where application-level encryption would be a necessary part of a sufficient solution. It isn't "real" security; it just happens to thwart real people from committing real crimes, as long as those crimes aren't lucrative enough that you get pillaged by a horde of professional hackers.
Instead, he has to go update all the reference and dependency information, which programs have to generate and update all the time anyway. I can't really think of a good reason this information needs to be saved to disk
It's a performance hack so it doesn't take ten minutes to open the kind of gigantor spreadsheets that are used for unofficial accounting and reporting in many companies. Too bad he didn't read the spec until after trying to edit the file. Maybe he would have found a simple way to indicate, "Please recalculate the dependency information at runtime, because the information in this file is missing or incorrect." Or maybe not. He doesn't quote enough of the spec to be sure.
All-or-nothing thinking has its place in computer security, but it isn't the only kind of security there is. Consider the case of clerical workers who routinely handle data that can be used to commit petty fraud. A certain amount of trust is necessary, and a certain amount of dishonesty is inevitable. The security situation here is not an all-or-nothing one: it is bad for the company when a clerk pulls off a petty scam, but it is bad in a limited, survivable way. It is also impossible to have perfect security, since the clerks must have access to the data to do their jobs. A certain amount of data leakage will happen even if clerks can only employ memory or written notes.
In this situation, a sufficiently large company will have a constant drip-drip-drip of petty dishonesty that costs time, money, and goodwill. Considering the technical ability of the average petty criminal, a bit of haphazard, poorly-thought-out application level encryption could eliminate a large percentage of the costly drip-drip-drip. A very shoddy job could be very, very valuable.
Application-level encryption can also be valuable when data needs to be preserved locally, but doesn't need to be accessed locally. When you have an extremely large number of machines in the field and need to capture a large amount of logging information from each, but you only ever read a very small percentage of that data, a cheap solution is to encrypt the logs locally using an asymmetric public-key algorithm. Then, when you need to access a log file, you can retrieve it from the computer where it is stored and decrypt it in a secure location. That way you don't let a large amount of unencrypted logging information build up on any vulnerable machine. You could also use asymmetric encryption to protect data that accumulates during the day for a nightly upload. This raises the bar from hacking a machine and stealing a file (an exploit that any middling hacker might be able to pull off using scripts) to actually hacking an application (which requires that someone with skill and ingenuity specifically target your application.)
I think it's the only way to interpret his point that is consistent with his own presentation of it. I'm not exaggerating or constructing a strawman. He was quite clear about his expectations: He wanted to open a spreadsheet document and make any changes that seemed simple and reasonable to him, without needing to read the spec, and he wanted the result to be conformant OOXML.
A more charitable reading would be the following: he's arguing that the standard, because it's based too closely on the legacy representations and algorithms used by Excel, is more complicated than it ought to be.
He argues that point pretty well later, but the first example doesn't support it at all. In order for large spreadsheets to be handled with decent performance, dependency information has to be cached in the saved files. He must understand this, because I just learned it from him today:-) A reasonable complaint would be if the OOXML way of doing this is poorly designed or biased towards Excel's implementation. Maybe that's the case, but he doesn't even bother to make that claim. Instead, his complaint is, "Gosh, this is complicated. In order to write a program that reads, modifies, and writes OOXML spreadsheet documents, you'd have to actually read the spec and maybe know something about how spreadsheet programs work."
Granted, the rest of the points seem substantial and much better argued, but you have to wonder why he started off with such a ludicrous example.
Exactly. He ignored the spec, made whatever changes seemed okay to him, and produced a non-standards-conforming document. With that kind of "I don't have time to read the spec" attitude you have to wonder how he came to care about international standards at all. It's actually a *good thing* (in the long run) for programs to reject clearly nonconformant documents instead of attempting to render them.
Some of his other points look good, though, and in any case, it just strains credulity that Microsoft would do something as disastrous as enabling interoperability with Office. Asking me to believe that Microsoft is making a good-faith effort at losing billions of dollars is like asking me to believe that water flows uphill.
Linux is often brought up as a great platform for development -- you get GCC, grep, Emacs and Vi, make, etc. But I too don't like this argument, because I don't like those tools. Emacs is a great editor (pretend I said "Vi" if that's your thing) and has some things that are nice for coding, but I'll take a true IDE in a second.
Well, I'm halfway on this point, since the two applications I spend the most time in (besides my browser) are Eclipse and Emacs. No IDE that I know of has a decent text editor and no text editor that I know of has decent IDE tools. It's a real problem that only exists for historical reasons. Personally, I prefer Emacs for everything except Java. C++ is evidently too grody a language to have decent tool support, and the dynamic languages of course are just text anyway:-)
So basically this comes down to the following: I don't have a good reason to switch.
Hmmm, if I told you you were a pawn in a global OS popularity contest, would that sway you? That's how I feel about much of the Linux advocacy stuff: A bunch of pimply-faced kids trying to force their friends and family to use Linux because it's important for their ego.
On the other hand, Microsoft is a corporation; their interests are narrowly focused on making money. Unix is a world that programmers built for themselves and each other. Unix assumes that every user is a guru in training, which is a wonderful thing, even for those who will never get very far. In eight years of using Linux, I've dealt with about a dozen different kinds of config files. Most of the time, I never have to even know they exist, but when the GUI facade proves insufficient, the mechanism behind it usually turns out to be clean, presentable, and acceptably documented in various places on the web. I hate working with config files -- in almost every case, I consider it a major UI failure when I have to edit a config file by hand -- but it is not as bad as having no fallback, as in Windows. When you work with any kind of Linux config files or command-line tools, you're dealing with a user interface that is designed to be as simple and easy as possible for the people who have to use it.
As far as Windows is concerned, if the GUI facade doesn't work, then game over, go home, wait for Microsoft to fix it. The stuff behind the facade in a Microsoft product is *supposed* to be shit, because it isn't part of the supported product interface, and Microsoft doesn't waste resources on something that isn't part of the supported interface. In fact, it actually helps Microsoft if the stuff behind the facade is inaccessible and/or undocumented, becaues it discourages users from going beyond the single official interface. I had to debug a problem between a C# SOAP client and gSoap server at work a few months ago, which meant running Visual Studio and using its "magic" web services code generation. It was torture, because there was exactly one right path for using Visual Studio, and it meant handing over all control to Visual Studio's automated tools. Every attempt I made to take control of one part of the process or another, or simply delve into the workings and understand them, was utterly thwarted. This would be fine if everything worked, but something was wrong, and the maddening opaqueness that Microsoft *intentionally* programmed into Visual Studio turned what should have been merely a laborious and boring debugging task into an epic struggle against the "Microsoft Way." Documentation on how Visual Studio worked internally was scarce, even using all my google-fu. All I managed to do was find and read the C# code generated by Visual Studio. Eventually I tracked the problem down to a known bug in Visual Studio 2005. Will not fix, wait for Orcas (currently scheduled to ship in February as Visual Studio 2008.)
Why in the world did Microsoft make this ordeal so unpleasant? Well, they're a for-profit corporation. That really covers it. Everything
What constantly gets left out is usability, installation needs to be simple enough that I can give my parents a CD/DVD and let them install it.... Installing software must not require editing config files and if additional components are needed then it should just be a click Yes to install additional components.
Yep. I'm a professional developer, been running Linux since the 20th century, and I just utterly failed to install Kubuntu (of all things!) on a box I built about a year ago out of cheap, standard-issue hardware. A number of things didn't work, but most notable were the monitor (I ended up stuck in 800x640 or something like that) and the network device configuration (utterly baffling.)
There needs to be a consistent UI between applications and components.
I think this is overrated. Complaints about UI inconsistency are a symptom of a general (and completely justified) lack of confidence with Linux. People aren't convinced they're savvy enough to handle Linux, so they're easily discouraged. People who aren't confident they can survive and cope with Windows -- there aren't many left anymore, but they exist -- have exactly the same complaints about inconsistencies in Windows. If you take an old geezer who's scared of computers and plop him in front of XP Professional with Office 2007, he'll talk your ear off about the confusing and (to him) arbitrary differences. To him, they're crippling. Of course, he's the exception -- virtually everybody handles the inconsistencies of Windows just fine, and in general they shrug off the disorientation of Windows application upgrades pretty quickly.
The difference between Windows and Linux is that people assume they can scrape by with Windows. By contrast, they know that someday, probably pretty quickly, they will run into something they simply cannot manage to do on Linux: printing, playing a movie, sending a fax, writing a double-layer DVD, who knows what. That knowledge sits in the back of their head, and every time they encounter a difficulty, they're tortured with self-doubt. Is this the stopping point? Is this the point where I'm too dumb or techno-illiterate to go any further? It's exactly the same torture that most non-techy adults had to suffer through in the eighties and nineties.
The way to cure it is to keep polishing the basic functions that challenge even somewhat savvy people today: printing, writing double-layer DVDs, Samba, etc. Grow the user base downward. Even technically minded people like myself have to make cost-benefit decisions about figuring out certain unpolished functionality. Make it usable for us before worrying about "Grandma." My parents and my sister are not going to put up with Linux until they know I can bail them out when they hit a difficulty. I can't even bail myself out sometimes. The last time I tried to set up printing under Linux was 2004. I'm not sure I'm ready to try again.
Installing software must not require editing config files and if additional components are needed then it should just be a click Yes to install additional components.
This is technically a solved problem. Ubuntu kicks ass at this. All that remains is manpower to package the applications, test the packages, and keep the repositories up to date.
A large part of it was that they wanted to build performance-critical enterprise server software, but wrote it mostly in a language that emphasized abstraction over performance, and was designed for portability, not performance. The language, of course, was Java.
On the large scale, performance is as much about reliability, portability, design, and refactorability as it is about benchmarks.
Reliability means you're free to spend more time thinking about design and rewriting code. Checked exceptions are a huge boon for making sure modules fail when they should and don't fail when they shouldn't. (Well, it's not exact, but it's a hell of a lot better than C and C++, where modules are typically heavily biased towards "don't fail at all, no matter what happens" or "die at the first hiccup to avoid corrupting data.") Time spend debugging core dumps and de-corrupting databases is time that could have been spent on performance testing and redesign.
Portability means you can drop a huge Sun box into your previously Linux-only server room and not worry about subtle bugs caused by the differences between Posix functionality in Linux and Solaris.
Design and refactorability are two sides of the same coin. It's easy to design APIs in any language that simply cannot be implemented efficiently. For an example of a poorly designed Java API that hurts performance for everyone who uses it, see this Google tech talk at 36:39. Note that the title of the slide is, "Effects of API Design Decisions on Performance are Real and Permanent." He's talking about externally published APIs, but internal APIs can end up being permanent, too, if other developers can't afford to let you muck with APIs or frameworks.
So, what determines when you're stuck with your mistakes and when you can fix them? First, it's important to discover mistakes early, so anything that helps you cobble a working system together quickly is a good thing. This isn't Java's strong suit unless you're comparing it to C or C++. Second, the less work and less risk is involved in adapting existing code to the changes, the more likely you'll be able to fix things. Java is an absolute miracle in this regard because of the tools and practices. Some languages have been around far longer than Java, and some languages are probably better designed for tool support than Java, but the combination of language simplicity and massive popularity has given Java an unbeatable array of tools. If you want unit testing, continuous integration, refactoring tools, mock objects, hands-off deployment (for automatic integration testing), and so forth, you can go to Barnes and Noble and pick up, um, approximately three moderately sized and priced paperbacks. Then it's a few months to set up and learn the tools. (It only takes a few weeks, really, since any reasonably experienced Java developer is already familiar with JUnit and refactoring IDEs.) With any other language you'd have to roll most of that yourself. Unless you're willing to make that huge commitment to building infrastructure, you have to be really, really picky about making large-scale changes, so most of the time you either stick with the first idea you implemented or suffer delays.
(Now, lots of languages *could* support tools well. A language's user base and culture count for a lot as well. Just post a question on comp.lang.lisp and ask about continuous integration or some-such, and some guy will reply about half an hour later with fifty lines of Common Lisp that does exactly what you asked for. Hey, that's great, but it takes years to get from that point to the point of Joe Average picking up a paperback that tells him how to download and configure a complete solution with a web interface, email alerts, and SCM integration. Lispers don't particularly care whether t
Hear, hear. I'm sure there are interesting issues in the OP's workplace that he can work on here, now, and in an indubitably real environment. He should start attacking the issues his coworkers struggle with. Does the app deploy smoothly? How much administration does it require? Can the interface be improved to save users time and brainpower? Can you decrease the training time of new employees or the number of technical support requests? Find a real, quantifiable problem, try to create a real solution, and see what happens. You'll learn so much more than if you try to create and test a enterprise-level scaling solution on your home network. With fake problems, you can go through the motions, but you'll never know if you're doing it right.
Real problems will bite back if your solution is half-baked, and I'm sure your company has plenty of real problems. If there aren't any urgent problems that are being neglected, then look for a new job NOW before the next wave of cost-cutting!
Nothing new or earth shattering here, but for some reason, said w. b.'s have developed the skill of 'asking people on mailing lists to do their work for them' as a substitute for real work.
I don't know what w.b.s are, but I have noticed many inappropriate newsgroup and mailing list questions from Indians that show more of a desire (or desperate need) to offload work than a need for assistance with a particular question.
I also get the feeling with many of those questions that the developer is hopelessly out of his depth. Must be a management issue -- hire cheap people who desperately need a job, then drop impossible tasks on them and watch them scramble. I'm sure it's satisfying if your measurement of management success is paying somebody almost nothing to work his ass off day and night, but I can't imagine that it ever results in usable software.
To clarify, by "don't know of" I mean "haven't demonstrated repeatably in practice." The internet has obviously opened up a lot of possibilities that haven't been explored yet. Developments along these lines will be tentative and exploratory, with many outright failures. Since we don't systematically validate and disseminate new educational ideas, those developments will have to spread around the educational community through the standard mode of rumor, superstition, fads, and miracle cures, further slowing things down. If we set our hearts on "reform," the "reform" we would get in most instances would just be the institutionalization of whatever the fad du jour is, which is even worse than letting things limp along as they are.
the organizational DNA of public schools is based on production-line methods. Production lines work only by using uniform methods to process uniform uniform materials into uniform products, and "individual variation" is outside of the paradigm.
You have a point, but attitudes are not the problem. Educators are very well indoctrinated into the philosophy you are promoting, which is on the whole a good thing, though it inspires its share of stupidity (as any philosophy does.) Individual variation is routinely rewarded in the form of honor rolls, academic recognition, contests, organized displays of student art and music, and so forth.
What is missing is that we don't know of other organizational structures that would provide better individual instruction at current staffing levels. Reform would be pointless unless it involves more spending, because we have little idea how to do better on current money. What we need is either more money or more research. Innovations need to be fostered on a small scale, verified on a larger scale, and then standardized nationally. Instead, we get faddishness and obsession with "hero" teachers who do great work but can't communicate anything to other teachers except inspirational slogans.
Less-simplistic metrics might help as well. Percentage-past-a-threshold metrics do tend to result in production-line thinking.
Re:Back in the days when the grass was greener...
on
Failing Our Geniuses
·
· Score: 1
In my school system, few kids were able to read when they entered kindergarten. Any class-conscious upper-middle-class white parents (my town was devoid of upper-class people) could get their precious babies into honors classes just by teaching their kids to read. Simply performing this basic parental responsibility gave their kids a head start that they coasted on all the way to high school. It wasn't until sophomore and junior year that tough teachers started chasing the stupid upper-middle-class white kids out of Honors classes.
Until that point the Honors classes included some real idiots. I'm talking about literally below average, double-digit-IQ students who were put on the gifted track and stayed there, dragging down the program, merely because they could read Green Eggs and Ham at age six.
Anyway, a three-track system is a tragic sham for kids in the top few percent. You might as well put them in a one-room schoolhouse. From where I was sitting, I couldn't tell the difference between the slower kids in AP Chemistry and the kids in Consumer Math. I thought they were all animals. It wasn't until I was able to spend time around other bright kids and develop social skills in a natural way (instead of struggling to relate to "animals") that I started to get along better with regular people and stopped being such an asshole.
More to the point, it would mean treating students as individuals and that would totally screw up the system.
I think you mean it wouldn't be possible to do cost-effectively. Kids aren't all self-starters, and most of the ones who fancy themselves as independent learners just digest textbooks and burrow their way into artistic dead ends. Smart kids need criticism and stimulation from other smart people, and you simply can't get that in an ordinary public school. Isolating kids from dumb people is the next-to-worst thing you can do. (Current policy happens to be the worst thing.) Smart kids should be allowed to interact with other kids and teachers of their ability level (and higher) so they can develop intellectually and learn social skills in a less distorted environment. That could mean sending the top 5% to state schools and the top 1% to regional schools for part of the year, or it could mean distance learning.
Students shouldn't be crippled socially and intellectually by sending them into isolation. They should get a balance between open-ended intellectual exploration, critical give-and-take with other students at their level, cooperative tasks, and regular studying. They should do this with other gifted students and specialist teachers. They should also have periods of regular contact with average students, because that's important, too. Contact with other talented kids actually improves social skills for dealing with regular people, so that won't be as burdensome as it might seem.
Just because isolating them from their slow peers is better than integrating them doesn't mean this is the best policy. Nobody learns well or does good work in complete isolation. Kids need stimulation and challenge from other bright, creative kids, and they need it from bright and educated adults. They need freedom as well, but freedom in isolation is stultifying.
Oh, and another thing, when a company comes under scrutiny for infractions committed by employees, there's often no way to distinguish between rogue employees operating under management radar and employees who have been given a wink and a nod by management. Companies should be held responsible for long-term policies systematically implemented by employees, even if they contradict official policy. Ideally, companies would be able to detect systematic noncompliance by their own employees, but for most things, it's only possible to be hypervigilant for a short period and then revert to trusting employees to police themselves and each other.
Just for your benefity probably since you're the only one who will see it.
Draconian policies like this are used to protect against people who refuse to change when policies change. At higher pay grades this is not as much of a problem, unless you're dealing with academics, but at low pay grades there are many people who take personal offense every time a policy changes. "I've been doing this job for five years, who do they think they are telling me how to do my job, blah blah blah" and after much threatening and cajoling they start implementing the new policy... but a year later you find out that they followed the new policy for three months and then went back to the old policy, nobody reported them, and now you have nine months of misfiled information, missing and unrecoverable financial data, illegal accounting, or in your case, infringements of HIPAA that result in who-knows-how-much liability for the organization.
If this sounds weird, let me assure you that it isn't. It's evidently a completely natural reaction for a nontrivial portion of the population, especially after a certain age. Some people feel so pushed around and humiliated by policy changes that they will fight them tooth and nail, endure disciplinary action against them, ignore warnings of termination, and finally end up canned. They'll do this for something as trivial as the way invoices are numbered or the way records are filed. They can't see it in terms of regulatory compliance or consistency across an organization. To them, it's just bullying. The only way to keep the organization out of serious legal trouble is to fire them.
This is all about power and market share, with only a small element of competition. Here's why:
The only place this image file format will make any difference is in small battery-powered devices such as cameras and cell phones. Camera companies will use it to save battery power. Consumers will buy the cameras because they want lighter cameras or longer battery life. They will plug the cameras into their computers and expect them to work. That means every non-Windows desktop system has to support the image format or appear deficient. This gives Microsoft power over everybody who makes software for desktop systems. Microsoft will turn that power into money.
"What's wrong with this?" you might ask. What's wrong with it is that it doesn't work for anybody else: nobody else has the power to make this happen without Microsoft's permission, no matter how valuable their idea is. Nobody is going to sell cameras that aren't guaranteed to work with all reasonably recent Windows computers. That means Microsoft has veto power on this kind of innovation and can use that power to grab a percentage of every good idea like this one.
Suppose Joe Blow in Albuquerque comes up with a brilliant idea for a flash drive filesystem. It can't be sold if it doesn't run under Windows. That means he has to take his invention to Microsoft, sign over whatever percentage they demand (since it's worth nothing at all without their approval,) and let them market it as a great Microsoft innovation. Microsoft doesn't produce anything in this scenario. They make money purely through their power to kill innovation.
Linux is ready and running on the desktops of vast numbers of people. The "ready for the desktop" issue almost always means "ready for me to foist onto my unenthusiastic but technologically deferential friends and relatives," and it only matters to two mostly overlapping groups of people:
Linux enthusiasts who obsess over desktop market share because they're worried about the social acceptability and social prestige of a brand they're ego-identified with.
Linux enthusiasts whose understanding of the world is challenged by the continuing prevalence of Windows.
The survival of Linux is assured. The free software movement is chugging patiently along; it's far from the theorized tipping point where it snowballs and takes over the world, but that depends on corporate and industial uptake, not home desktop use. Linux provides a pretty decent desktop environment for those who want to use it. These days, it's easier to rid your home of Windows than to be a vegetarian.
The only hard thing is pushing Linux on people who don't want it. Who cares? Let them be.
I think a hard separation between source and artwork makes sense.
"Source" and "artwork" are overlapping categories. I'm not sure how you meant to draw the distinction, but I would say that the "source" of a game is everything that is required to build and run the game, except for elements that are contributed by third parties: compilers, libraries, OS, etc. If a game's artwork is withheld, then the game can't be re-created.
As for RHEL, I wouldn't call it 100% open-source, but I would give them partial credit depending on how much you can get running for how little effort. It's probably just a matter of a few branding elements that could easily be replaced by generic gifs without degrading the experience.
I guess I did beg for that objection by saying "source code" instead of "source," but I wouldn't consider a game "open" without the content. If you can't reproduce the game, then you haven't open-sourced the game, just the game engine.
Do you think they all depend on proprietary libraries and run on Microsoft servers?
Unless you mean they could release the actual source code for the game, but I think there's a good reason for keeping the code secret. My impression is that commercial MMORPGs get a lot of unpaid admin work from people who enjoy the prestige, enjoy the power, and enjoy being useful. A commercial company that open-sourced its engine would surely have to compete with entirely free alternatives staffed by volunteers. The only way around it would be to make sure the computing load is non-distributable, so that it required extremely powerful servers to run.
Slashdot Mirror
Is it obvious to "a person having ordinary skill in the art?" Some federal judges consider the guy who goes around replacing network cables to be a typical "person having ordinary skill" in the "art" of "doing stuff with computers." That means anyone who has a CS degree or can write a single line of code is waaaaay too smart to be included in the nonobviousness test, and you can patent any damn thing you want as long as it's useful and involves programming. The patent holds until someone produces evidence of prior art.
I have two questions that are going to sound a bit trollish, so I apologize in advance, but you sound like the right person to ask. I really wouldn't give a damn about this except that I buy a hard drive now and then and don't like to buy from companies that jerk people around.
According to the article, the AAK drives perform a bit better than the AAE drives on the carefully engineered server-oriented benchmarks, the AAK drives perform significantly worse on very simplistic benchmarks (which are somewhat meaningful since they happen to measure things that cause some desktop users to sit and wait,) and on workstation-oriented benchmarks it's a wash. So, there's actually a significant chunk of users who would prefer the AAK drives over the AAE drives and another chunk who wouldn't care much about the difference, yet server-oriented people aren't posting here complaining that they might accidentally buy an AAE drive and get 4% less performance or whatever the difference is. First question: Is this just a case of people putting too much stock in the performance measurements that they themselves can easily perform, as opposed to the complicated server or workstation benchmarks that probably reflect real usage better? I understand that the differences in the simplistic benchmarks are larger, but you would expect real performance to be more like the complicated benchmarks than the simple ones. (After all, how often do people copy large files locally?)
Second, since it hasn't been mentioned, I assume that Seagate doesn't specify the performance of this model well enough that the AAK drives can be called "out of spec." Also, each drive is evidently superior at some tasks, so the big deal is that parts with different performance characteristics are being sold under the same product number. Forgive me if this sounds cynical, but isn't this completely normal with consumer-grade, loosely specified hardware?
Not necessarily -- they could be servers or appliances sitting on client sites. For instance, if you provide IT services for other businesses, you might install network appliances at their business sites. The logs might be uploaded during off-peak hours, or they might simply sit on the machine until they get deleted or until you decide you need to look at them to investigate a network failure or intrusion. These logs may contain information that can be used to plan attacks, such as network configuration info and package versions, so it's nice if they can't be viewed even by someone who roots the box. (You may want to keep the information secret from your customers, so physical access is a concern, too.)
Or the computer might be located in a hospital, where it controls a medical device or gathers data from medical devices. The IT staff who do maintenance and monitoring on those systems might not be authorized to view patient information, so anything related to patient information might need to be dumped into a special encrypted log so that it can only be viewed by a proper authority, not just by anyone who has root privileges on the device. It doesn't protect you against an IT guy who has the skill to tamper with the binary that logs the data, but there aren't very many of those. It does protect you against lots of scenarios that a non-encrypted log file would invite -- for instance, an IT guy thinking, "I'll just take a quick look in that log that I'm not supposed to look at. It won't hurt anybody and will save a ton of time. I'll just grep out what I need and then look at it in emacs.... Oh, crap, this system doesn't have emacs installed, but I can copy the data to a machine that has emacs." It might even help legally if you can't view the log without doing something sophisticated and outrageously illegal (e.g., patching an executable in a medical device) as opposed to something that can be done in a simple and innocent-seeming way (e.g., an IT guy grepping through a log file.)
I'm actually talking about asymmetric encryption, where a program has the information necessary to encrypt data but can't decrypt the data after it encrypts it. A simple example is when you PGP a document using someone else's public key. You can't decrypt the resulting file, unless you also encrypt it using your own key. (It's kind of embarrassing when you have to call somebody and ask them what was in the document you sent them last month, because you forgot to use your own key as well. Not that that ever happened to me, of course....)
Absolutely; there aren't very many scenarios where application-level encryption would be a necessary part of a sufficient solution. It isn't "real" security; it just happens to thwart real people from committing real crimes, as long as those crimes aren't lucrative enough that you get pillaged by a horde of professional hackers.
All-or-nothing thinking has its place in computer security, but it isn't the only kind of security there is. Consider the case of clerical workers who routinely handle data that can be used to commit petty fraud. A certain amount of trust is necessary, and a certain amount of dishonesty is inevitable. The security situation here is not an all-or-nothing one: it is bad for the company when a clerk pulls off a petty scam, but it is bad in a limited, survivable way. It is also impossible to have perfect security, since the clerks must have access to the data to do their jobs. A certain amount of data leakage will happen even if clerks can only employ memory or written notes.
In this situation, a sufficiently large company will have a constant drip-drip-drip of petty dishonesty that costs time, money, and goodwill. Considering the technical ability of the average petty criminal, a bit of haphazard, poorly-thought-out application level encryption could eliminate a large percentage of the costly drip-drip-drip. A very shoddy job could be very, very valuable.
Application-level encryption can also be valuable when data needs to be preserved locally, but doesn't need to be accessed locally. When you have an extremely large number of machines in the field and need to capture a large amount of logging information from each, but you only ever read a very small percentage of that data, a cheap solution is to encrypt the logs locally using an asymmetric public-key algorithm. Then, when you need to access a log file, you can retrieve it from the computer where it is stored and decrypt it in a secure location. That way you don't let a large amount of unencrypted logging information build up on any vulnerable machine. You could also use asymmetric encryption to protect data that accumulates during the day for a nightly upload. This raises the bar from hacking a machine and stealing a file (an exploit that any middling hacker might be able to pull off using scripts) to actually hacking an application (which requires that someone with skill and ingenuity specifically target your application.)
I think it's the only way to interpret his point that is consistent with his own presentation of it. I'm not exaggerating or constructing a strawman. He was quite clear about his expectations: He wanted to open a spreadsheet document and make any changes that seemed simple and reasonable to him, without needing to read the spec, and he wanted the result to be conformant OOXML.
He argues that point pretty well later, but the first example doesn't support it at all. In order for large spreadsheets to be handled with decent performance, dependency information has to be cached in the saved files. He must understand this, because I just learned it from him today
Granted, the rest of the points seem substantial and much better argued, but you have to wonder why he started off with such a ludicrous example.
Exactly. He ignored the spec, made whatever changes seemed okay to him, and produced a non-standards-conforming document. With that kind of "I don't have time to read the spec" attitude you have to wonder how he came to care about international standards at all. It's actually a *good thing* (in the long run) for programs to reject clearly nonconformant documents instead of attempting to render them.
Some of his other points look good, though, and in any case, it just strains credulity that Microsoft would do something as disastrous as enabling interoperability with Office. Asking me to believe that Microsoft is making a good-faith effort at losing billions of dollars is like asking me to believe that water flows uphill.
Well, I'm halfway on this point, since the two applications I spend the most time in (besides my browser) are Eclipse and Emacs. No IDE that I know of has a decent text editor and no text editor that I know of has decent IDE tools. It's a real problem that only exists for historical reasons. Personally, I prefer Emacs for everything except Java. C++ is evidently too grody a language to have decent tool support, and the dynamic languages of course are just text anyway :-)
Hmmm, if I told you you were a pawn in a global OS popularity contest, would that sway you? That's how I feel about much of the Linux advocacy stuff: A bunch of pimply-faced kids trying to force their friends and family to use Linux because it's important for their ego.
On the other hand, Microsoft is a corporation; their interests are narrowly focused on making money. Unix is a world that programmers built for themselves and each other. Unix assumes that every user is a guru in training, which is a wonderful thing, even for those who will never get very far. In eight years of using Linux, I've dealt with about a dozen different kinds of config files. Most of the time, I never have to even know they exist, but when the GUI facade proves insufficient, the mechanism behind it usually turns out to be clean, presentable, and acceptably documented in various places on the web. I hate working with config files -- in almost every case, I consider it a major UI failure when I have to edit a config file by hand -- but it is not as bad as having no fallback, as in Windows. When you work with any kind of Linux config files or command-line tools, you're dealing with a user interface that is designed to be as simple and easy as possible for the people who have to use it.
As far as Windows is concerned, if the GUI facade doesn't work, then game over, go home, wait for Microsoft to fix it. The stuff behind the facade in a Microsoft product is *supposed* to be shit, because it isn't part of the supported product interface, and Microsoft doesn't waste resources on something that isn't part of the supported interface. In fact, it actually helps Microsoft if the stuff behind the facade is inaccessible and/or undocumented, becaues it discourages users from going beyond the single official interface. I had to debug a problem between a C# SOAP client and gSoap server at work a few months ago, which meant running Visual Studio and using its "magic" web services code generation. It was torture, because there was exactly one right path for using Visual Studio, and it meant handing over all control to Visual Studio's automated tools. Every attempt I made to take control of one part of the process or another, or simply delve into the workings and understand them, was utterly thwarted. This would be fine if everything worked, but something was wrong, and the maddening opaqueness that Microsoft *intentionally* programmed into Visual Studio turned what should have been merely a laborious and boring debugging task into an epic struggle against the "Microsoft Way." Documentation on how Visual Studio worked internally was scarce, even using all my google-fu. All I managed to do was find and read the C# code generated by Visual Studio. Eventually I tracked the problem down to a known bug in Visual Studio 2005. Will not fix, wait for Orcas (currently scheduled to ship in February as Visual Studio 2008.)
Why in the world did Microsoft make this ordeal so unpleasant? Well, they're a for-profit corporation. That really covers it. Everything
Yep. I'm a professional developer, been running Linux since the 20th century, and I just utterly failed to install Kubuntu (of all things!) on a box I built about a year ago out of cheap, standard-issue hardware. A number of things didn't work, but most notable were the monitor (I ended up stuck in 800x640 or something like that) and the network device configuration (utterly baffling.)
I think this is overrated. Complaints about UI inconsistency are a symptom of a general (and completely justified) lack of confidence with Linux. People aren't convinced they're savvy enough to handle Linux, so they're easily discouraged. People who aren't confident they can survive and cope with Windows -- there aren't many left anymore, but they exist -- have exactly the same complaints about inconsistencies in Windows. If you take an old geezer who's scared of computers and plop him in front of XP Professional with Office 2007, he'll talk your ear off about the confusing and (to him) arbitrary differences. To him, they're crippling. Of course, he's the exception -- virtually everybody handles the inconsistencies of Windows just fine, and in general they shrug off the disorientation of Windows application upgrades pretty quickly.
The difference between Windows and Linux is that people assume they can scrape by with Windows. By contrast, they know that someday, probably pretty quickly, they will run into something they simply cannot manage to do on Linux: printing, playing a movie, sending a fax, writing a double-layer DVD, who knows what. That knowledge sits in the back of their head, and every time they encounter a difficulty, they're tortured with self-doubt. Is this the stopping point? Is this the point where I'm too dumb or techno-illiterate to go any further? It's exactly the same torture that most non-techy adults had to suffer through in the eighties and nineties.
The way to cure it is to keep polishing the basic functions that challenge even somewhat savvy people today: printing, writing double-layer DVDs, Samba, etc. Grow the user base downward. Even technically minded people like myself have to make cost-benefit decisions about figuring out certain unpolished functionality. Make it usable for us before worrying about "Grandma." My parents and my sister are not going to put up with Linux until they know I can bail them out when they hit a difficulty. I can't even bail myself out sometimes. The last time I tried to set up printing under Linux was 2004. I'm not sure I'm ready to try again.
This is technically a solved problem. Ubuntu kicks ass at this. All that remains is manpower to package the applications, test the packages, and keep the repositories up to date.
On the large scale, performance is as much about reliability, portability, design, and refactorability as it is about benchmarks.
Reliability means you're free to spend more time thinking about design and rewriting code. Checked exceptions are a huge boon for making sure modules fail when they should and don't fail when they shouldn't. (Well, it's not exact, but it's a hell of a lot better than C and C++, where modules are typically heavily biased towards "don't fail at all, no matter what happens" or "die at the first hiccup to avoid corrupting data.") Time spend debugging core dumps and de-corrupting databases is time that could have been spent on performance testing and redesign.
Portability means you can drop a huge Sun box into your previously Linux-only server room and not worry about subtle bugs caused by the differences between Posix functionality in Linux and Solaris.
Design and refactorability are two sides of the same coin. It's easy to design APIs in any language that simply cannot be implemented efficiently. For an example of a poorly designed Java API that hurts performance for everyone who uses it, see this Google tech talk at 36:39. Note that the title of the slide is, "Effects of API Design Decisions on Performance are Real and Permanent." He's talking about externally published APIs, but internal APIs can end up being permanent, too, if other developers can't afford to let you muck with APIs or frameworks.
So, what determines when you're stuck with your mistakes and when you can fix them? First, it's important to discover mistakes early, so anything that helps you cobble a working system together quickly is a good thing. This isn't Java's strong suit unless you're comparing it to C or C++. Second, the less work and less risk is involved in adapting existing code to the changes, the more likely you'll be able to fix things. Java is an absolute miracle in this regard because of the tools and practices. Some languages have been around far longer than Java, and some languages are probably better designed for tool support than Java, but the combination of language simplicity and massive popularity has given Java an unbeatable array of tools. If you want unit testing, continuous integration, refactoring tools, mock objects, hands-off deployment (for automatic integration testing), and so forth, you can go to Barnes and Noble and pick up, um, approximately three moderately sized and priced paperbacks. Then it's a few months to set up and learn the tools. (It only takes a few weeks, really, since any reasonably experienced Java developer is already familiar with JUnit and refactoring IDEs.) With any other language you'd have to roll most of that yourself. Unless you're willing to make that huge commitment to building infrastructure, you have to be really, really picky about making large-scale changes, so most of the time you either stick with the first idea you implemented or suffer delays.
(Now, lots of languages *could* support tools well. A language's user base and culture count for a lot as well. Just post a question on comp.lang.lisp and ask about continuous integration or some-such, and some guy will reply about half an hour later with fifty lines of Common Lisp that does exactly what you asked for. Hey, that's great, but it takes years to get from that point to the point of Joe Average picking up a paperback that tells him how to download and configure a complete solution with a web interface, email alerts, and SCM integration. Lispers don't particularly care whether t
Hear, hear. I'm sure there are interesting issues in the OP's workplace that he can work on here, now, and in an indubitably real environment. He should start attacking the issues his coworkers struggle with. Does the app deploy smoothly? How much administration does it require? Can the interface be improved to save users time and brainpower? Can you decrease the training time of new employees or the number of technical support requests? Find a real, quantifiable problem, try to create a real solution, and see what happens. You'll learn so much more than if you try to create and test a enterprise-level scaling solution on your home network. With fake problems, you can go through the motions, but you'll never know if you're doing it right. Real problems will bite back if your solution is half-baked, and I'm sure your company has plenty of real problems. If there aren't any urgent problems that are being neglected, then look for a new job NOW before the next wave of cost-cutting!
I don't know what w.b.s are, but I have noticed many inappropriate newsgroup and mailing list questions from Indians that show more of a desire (or desperate need) to offload work than a need for assistance with a particular question.
I also get the feeling with many of those questions that the developer is hopelessly out of his depth. Must be a management issue -- hire cheap people who desperately need a job, then drop impossible tasks on them and watch them scramble. I'm sure it's satisfying if your measurement of management success is paying somebody almost nothing to work his ass off day and night, but I can't imagine that it ever results in usable software.
To clarify, by "don't know of" I mean "haven't demonstrated repeatably in practice." The internet has obviously opened up a lot of possibilities that haven't been explored yet. Developments along these lines will be tentative and exploratory, with many outright failures. Since we don't systematically validate and disseminate new educational ideas, those developments will have to spread around the educational community through the standard mode of rumor, superstition, fads, and miracle cures, further slowing things down. If we set our hearts on "reform," the "reform" we would get in most instances would just be the institutionalization of whatever the fad du jour is, which is even worse than letting things limp along as they are.
What is missing is that we don't know of other organizational structures that would provide better individual instruction at current staffing levels. Reform would be pointless unless it involves more spending, because we have little idea how to do better on current money. What we need is either more money or more research. Innovations need to be fostered on a small scale, verified on a larger scale, and then standardized nationally. Instead, we get faddishness and obsession with "hero" teachers who do great work but can't communicate anything to other teachers except inspirational slogans.
Less-simplistic metrics might help as well. Percentage-past-a-threshold metrics do tend to result in production-line thinking.
In my school system, few kids were able to read when they entered kindergarten. Any class-conscious upper-middle-class white parents (my town was devoid of upper-class people) could get their precious babies into honors classes just by teaching their kids to read. Simply performing this basic parental responsibility gave their kids a head start that they coasted on all the way to high school. It wasn't until sophomore and junior year that tough teachers started chasing the stupid upper-middle-class white kids out of Honors classes.
Until that point the Honors classes included some real idiots. I'm talking about literally below average, double-digit-IQ students who were put on the gifted track and stayed there, dragging down the program, merely because they could read Green Eggs and Ham at age six.
Anyway, a three-track system is a tragic sham for kids in the top few percent. You might as well put them in a one-room schoolhouse. From where I was sitting, I couldn't tell the difference between the slower kids in AP Chemistry and the kids in Consumer Math. I thought they were all animals. It wasn't until I was able to spend time around other bright kids and develop social skills in a natural way (instead of struggling to relate to "animals") that I started to get along better with regular people and stopped being such an asshole.
Students shouldn't be crippled socially and intellectually by sending them into isolation. They should get a balance between open-ended intellectual exploration, critical give-and-take with other students at their level, cooperative tasks, and regular studying. They should do this with other gifted students and specialist teachers. They should also have periods of regular contact with average students, because that's important, too. Contact with other talented kids actually improves social skills for dealing with regular people, so that won't be as burdensome as it might seem.
Just because isolating them from their slow peers is better than integrating them doesn't mean this is the best policy. Nobody learns well or does good work in complete isolation. Kids need stimulation and challenge from other bright, creative kids, and they need it from bright and educated adults. They need freedom as well, but freedom in isolation is stultifying.
Oh, and another thing, when a company comes under scrutiny for infractions committed by employees, there's often no way to distinguish between rogue employees operating under management radar and employees who have been given a wink and a nod by management. Companies should be held responsible for long-term policies systematically implemented by employees, even if they contradict official policy. Ideally, companies would be able to detect systematic noncompliance by their own employees, but for most things, it's only possible to be hypervigilant for a short period and then revert to trusting employees to police themselves and each other.
Just for your benefity probably since you're the only one who will see it.
Draconian policies like this are used to protect against people who refuse to change when policies change. At higher pay grades this is not as much of a problem, unless you're dealing with academics, but at low pay grades there are many people who take personal offense every time a policy changes. "I've been doing this job for five years, who do they think they are telling me how to do my job, blah blah blah" and after much threatening and cajoling they start implementing the new policy... but a year later you find out that they followed the new policy for three months and then went back to the old policy, nobody reported them, and now you have nine months of misfiled information, missing and unrecoverable financial data, illegal accounting, or in your case, infringements of HIPAA that result in who-knows-how-much liability for the organization.
If this sounds weird, let me assure you that it isn't. It's evidently a completely natural reaction for a nontrivial portion of the population, especially after a certain age. Some people feel so pushed around and humiliated by policy changes that they will fight them tooth and nail, endure disciplinary action against them, ignore warnings of termination, and finally end up canned. They'll do this for something as trivial as the way invoices are numbered or the way records are filed. They can't see it in terms of regulatory compliance or consistency across an organization. To them, it's just bullying. The only way to keep the organization out of serious legal trouble is to fire them.
This is all about power and market share, with only a small element of competition. Here's why:
The only place this image file format will make any difference is in small battery-powered devices such as cameras and cell phones. Camera companies will use it to save battery power. Consumers will buy the cameras because they want lighter cameras or longer battery life. They will plug the cameras into their computers and expect them to work. That means every non-Windows desktop system has to support the image format or appear deficient. This gives Microsoft power over everybody who makes software for desktop systems. Microsoft will turn that power into money.
"What's wrong with this?" you might ask. What's wrong with it is that it doesn't work for anybody else: nobody else has the power to make this happen without Microsoft's permission, no matter how valuable their idea is. Nobody is going to sell cameras that aren't guaranteed to work with all reasonably recent Windows computers. That means Microsoft has veto power on this kind of innovation and can use that power to grab a percentage of every good idea like this one.
Suppose Joe Blow in Albuquerque comes up with a brilliant idea for a flash drive filesystem. It can't be sold if it doesn't run under Windows. That means he has to take his invention to Microsoft, sign over whatever percentage they demand (since it's worth nothing at all without their approval,) and let them market it as a great Microsoft innovation. Microsoft doesn't produce anything in this scenario. They make money purely through their power to kill innovation.
The survival of Linux is assured. The free software movement is chugging patiently along; it's far from the theorized tipping point where it snowballs and takes over the world, but that depends on corporate and industial uptake, not home desktop use. Linux provides a pretty decent desktop environment for those who want to use it. These days, it's easier to rid your home of Windows than to be a vegetarian.
The only hard thing is pushing Linux on people who don't want it. Who cares? Let them be.
"Source" and "artwork" are overlapping categories. I'm not sure how you meant to draw the distinction, but I would say that the "source" of a game is everything that is required to build and run the game, except for elements that are contributed by third parties: compilers, libraries, OS, etc. If a game's artwork is withheld, then the game can't be re-created.
As for RHEL, I wouldn't call it 100% open-source, but I would give them partial credit depending on how much you can get running for how little effort. It's probably just a matter of a few branding elements that could easily be replaced by generic gifs without degrading the experience.
I guess I did beg for that objection by saying "source code" instead of "source," but I wouldn't consider a game "open" without the content. If you can't reproduce the game, then you haven't open-sourced the game, just the game engine.
Do you think they all depend on proprietary libraries and run on Microsoft servers?
Unless you mean they could release the actual source code for the game, but I think there's a good reason for keeping the code secret. My impression is that commercial MMORPGs get a lot of unpaid admin work from people who enjoy the prestige, enjoy the power, and enjoy being useful. A commercial company that open-sourced its engine would surely have to compete with entirely free alternatives staffed by volunteers. The only way around it would be to make sure the computing load is non-distributable, so that it required extremely powerful servers to run.