I can't tell the number of times I've had a spec open in one monitor, and whatever it was I was working on open in the other. Glancing back and forth between screens is a lot faster than grabbing the mouse, clicking on the taskbar icon, absorbing as much as possible, clicking back, and repositioning your cursor.
Faster, and less error prone.
For years, people have been talking about paperless offices, but that can't happen until computer displays are as convenient and as pervasive as paper already is. That means you not two displays, but dozens in an office. They'll cover your desktops and walls the way printouts, memos, yellow-stickies, posters and memoes already do. Not feasible yet, but we're getting there.
You think things are less paranoid now? There's more orbital surveillance now than ever! This is "quaint" only because it assumed that orbital surveillance required somebody to be physically present.
Back in the 40s and 50s, there was a lot of talk about doing things like surveillance (you can see a lot) and communications (a lot of people can see you) from orbit. One common assumption (which turned out to be correct) was that these things would be extremely important in the near future. Another assumption (which turned out to be totally wrong) was that this would be done by sending people to go live in orbit. Once there, they'd use photography, electronics, and other technology that wouldn't be much more advanced that what people were familiar with. You can see this in Arthur C. Clarke's original proposals for communications satellites and in fiction from Clarke, Heinlen, and others.
What really happened, of course, is that rocket technology progressed relatively slowly, while electronics progressed very rapidly. So long before it was practical to a space station in orbit, it was practical to put a simple electronic gadget in orbit that would do all those chores pretty cheaply. Kind of sad, really -- if building better rockets had been more of an economic and military necessity, we'd probably be the space-going civilization that eveybody back in the 50s assumed we would be.
Then again, the need to build smaller and more reliable electronics did a lot to jump-start the computer revolution -- so we mustn't complain too much!
That still comes down to customizing Wine. This is something you can do yourself, or you can hire a consultant to do it for you. If you hire a consultant, CodeWeavers is probably a good bet (they invented Wine, so they presumably know something about it) but they're hardly the only Wine consultants on the block.
All of which has nothing to do with CrossOver Office. Which (I'll say it a third and last time, then give up) is just a prepackaged set of Wine configurations.
Dude, think it through. As I said before, CrossOver Office is just Wine pre-configured to support a list of programs. If your program is not on that list, CrossOver Office won't do you any good. Since the program the guy's trying to run is an "industry-specific application" I think it's a safe bet that it's not on the list.
You can probably use Wine to support your one Windows app. Not easy, but doable.
Crossover Office won't help you. It's just Wine pre-configured to support a lot of standard apps. People buy it to save themselves the (severe) headaches of hand-configuring Wine.
All the other choices you mention are ones you absolutely must not consider. Why? Because they defeat your primary purpose. Which is not just to get this one Windows app working. It's to maintain Linux as your primary desktop environment. If keeping Linux supreme in your workplace is your primary goal, then you must find a way to allow your users to run this app under Linux. If you force them to fire up a separate Windows environment just to run one program, you're telling them that Linux can't meet their needs. Eventually, they're going to say to each other, "Why are you using this stupid system that the geeks like, but doesn't run all the programs we use? Why don't we just run Windows?"
Java came out 1995ish. I'm pretty sure Smalltalk was GC'd, and that was from 1969. I'm pretty sure Simula was GC'd, and that was from 1964.
You're right. In fact, the HotSpot VM, which is now Sun's standard Java VM, was originally conceived as a Smalltalk VM by Animorphic Systems. Then Sun, looking to beef up its own feeble VMs, bought Animorphic in 1997 and folded them into JavaSoft.
But Smalltalk never got anything like the acceptance that Java got. It was just too far away from the way most programmers work. So even though there have been first-rate Smalltalk implementations from the very beginning -- and work on Smalltalk continues to this day -- it's never been a major contender as a programming language.
Java, by contrast, made enough comprimises with C++-style programming to be quickly accepted by professional developers. Perhaps a little too quickly, because Java's reputation for poor performance was firmly established by the horrible VMs and compilers Sun released early on.
So now.NET what people first think of when they think of VMs, because Microsoft has grabbed the ball that Sun dropped. They'll certainly drop it too, but that only makes it even more sad.
You're right -- memory management can make a lot of difference. People tend to assume that pure native code is always going to be faster than VMs such as Java or.NET , because there's no interpretation layer. Which makes the common mistake of associating all performance issues with one well-known bottleneck. With big programs, getting the most out of your memory is at least as important as getting the most out of your processor.
It's a little sad that when you raise this issue, you immediately think of.NET. Java was there first. But Sun's early Java implementations actually had pretty severe memory leaks, firmly establishing Java's reputation as a low-performance platform.
Anyway, it's a moot point. All the major browsers are implemented in C++, which doesn't support VM-style memory management. There used to be several Java-based web browser projects, but none of them really got beyond the demo phase.
Rote? Knowing industry best-practices is rote these days?
If saying "best practices" is just an excuse for not thinking for yourself, damn right it's rote. I'm protecting a stupid Wikipedia account, not a 7-figure bank account. The amount of effort you go to to protect something be proportional to the thing you're protect. Picking a mean level of security and applying it when it's both too strong and too weak is stupid.
... but I can't see this as anything more than a much belated, empty gesture on Microsoft's part.
Really it's not even that. Going to XML-based formats is not "opening up" the format. It's just making it easier to reverse-engineer the format. And the truth is that Microsoft formats have never been hard to reverse-engineer. All the leading word processors -- Open Office, WordPerfect, Lotus -- have decent import/export filters for Word binary format.
I know what you're saying: "Bullshit! When I import a Word document into OO, I get a total mess!" But that's not because OO can't parse the data in the Word file. That's because word processor files are full of messy little embedded formatting instructions that are very difficult to exactly translate into another format. It's like tearing down a house, exactly analyzing how the house was put together as you go, and then trying to rebuild the same house with completely different materials. Unless the house is a really simple structure, it's practically impossible to end up with exactly the same house.
Everyone seems to think that using XML instead of binary magically eliminates such formatting issues. Not true. XML is just a means to an end, and that end is content-presentation separation. If you separate all your presentation instructions into a separate stylesheet, then you can impose proper structure on your document and make it app-portable. You don't need XML to do that -- XML just makes it less work, because XML parsing is standardized.
But somebody hacking out a memo or a white paper can't be bothered with issues like that. They just need a document that looks good and is ready for the 2pm meeting. So their document is content and presentation all mixed up. Which isn't going to be app portable, whether the format is binary, RTF, or XML.
Microsoft isn't going to XML because they've suddenly got the open format religion. Microsoft is going to XML because that's the state of the art for data storage and transmission. It helps their apps interact with SOAP servers, XML-based filesystems, XML-based databases, XML-base content-management systems, etc. In theory, these could all be non-Microsoft softwares, but in practice Microsoft will do what they've always done: introduce silly little incompatibilites that will make everybody else jump through hoops if they want to interoperate. The incompatibilities will be easier to identify in XML-based files, but they'll still be there.
The fundamental compatibility problem is Microsoft's arrogant corporate culture that puts getting their way ahead of standardization. Until that changes, no "open format" is going to fix the problem.
My experience with LaCie makes it very unlikely I will buy anything with that label, for any price, regardless of quality. Poor designs, bad warantees, no U.S. tech support.
CRTs are ancient. Not just by virtue of being around since 1897. Even the name harks back to an earlier era of science. They work by virtue of a mysterious thing called "cathode rays". A better term would be "electron beams", but electrons hadn't been discovered when cathode rays were first observed!
Strong is relative. Arnold is stronger than I am, but not as strong as Superman. Your rote suggestion that I use a "full" character set only doubles the entropy of my password. If you want to follow that argument to its logical conclusion, you should insist that a password isn't "strong" unless it cantains non-Latin characters (Hebrew, Cyrillic, Kanji, Hangul...) which would increase the entropy by several orders of magnitude. But that would make the password very difficult to enter, so of course everybody limits themselves to characters they're familiar with. I choose a further tradeoff that cuts my entropy in half but still makes my passwords stronger than any tool anybody's likely to bring to bear.
Security is always about tradeoffs. If you're that paranoid about password protected access, you shouldn't use it at all.
All of which assumes that current models of geology and radioactive decay are even close to accurate. I don't know enough to have an opinion, but I seem to recall a time when 3 billion was the "official" figure. I kind of resent being "corrected" for citing an number which was valid the last time I read about the topic.
Zonk, if you don't word your headlines more carefully, you're just begging people to make silly posts like this one: Earth is still in beta? After 3 billion years?
I agree with you on every point. Unfortunately, EMACS and Vi zealots mostly refuse to acknowledge these issues. Which mostly doesn't matter, except that many of them are also OSS zealots, and their efforts to free us all from the Microsoft Monoculture are badly hampered by their inability to grasp the concept of lockin.
It seems rumors of the franchise's demise were greatly exaggerated.
Nothing ever really dies in Hollywood -- it just gets put on the shelf. But when a franchise has no plans except "maybe we'll do a movie in three years", it's as close to dead as it ever will be.
That's one approach. Another is to upgrade to a modern editor.
Of course, that's easier said than done. I've been telling myself for years that Vi (or rather Vim, which has pretty much displaced its prototype) is totally obsolete, since its most important design constraints (must work on a time-sharing system over a 300 bps line connected to a primitive dumb terminal) no longer apply. But all the various editors I've tried seem to not be worth the trouble. Though that might have been an excuse...
Lately, I've been playing with jEdit which absolutely demolishes every excuse I have for not switching to it. But every time I face the task of retooling my Vim macros and customizations for jEdit, and retooling my aging brain to use jEdit's interaction paradigm, I suffer a total failure of nerve. Help, I'm locked in and I can't get up!
It's funny that you should say this, and then go on to talk about InfoZip, a program full of precisely the problems that good software engineering practices are supposed to prevent. It sounds like porting doesn't enforce these practices -- rather, it raises the cost of not following them!
Individual keys are not that hard on you pinky. It's when you have to hit three or four keys as a single chord that you start getting stress injuries.
Not that Bill Joy is more ergonomically aware than Richard Stallman. It's just that when he invented Vi, he had to support the cheapo terminals at UC Berkely, which didn't have screen buffers, programmability, or fancy modifier keys. So he simplified the editing model, and forced the user to maintain state information in wetware. Which make vi rather less sophisticated, but a lot easier to keyboard for.
Slashdot Mirror
For years, people have been talking about paperless offices, but that can't happen until computer displays are as convenient and as pervasive as paper already is. That means you not two displays, but dozens in an office. They'll cover your desktops and walls the way printouts, memos, yellow-stickies, posters and memoes already do. Not feasible yet, but we're getting there.
Back in the 40s and 50s, there was a lot of talk about doing things like surveillance (you can see a lot) and communications (a lot of people can see you) from orbit. One common assumption (which turned out to be correct) was that these things would be extremely important in the near future. Another assumption (which turned out to be totally wrong) was that this would be done by sending people to go live in orbit. Once there, they'd use photography, electronics, and other technology that wouldn't be much more advanced that what people were familiar with. You can see this in Arthur C. Clarke's original proposals for communications satellites and in fiction from Clarke, Heinlen, and others.
What really happened, of course, is that rocket technology progressed relatively slowly, while electronics progressed very rapidly. So long before it was practical to a space station in orbit, it was practical to put a simple electronic gadget in orbit that would do all those chores pretty cheaply. Kind of sad, really -- if building better rockets had been more of an economic and military necessity, we'd probably be the space-going civilization that eveybody back in the 50s assumed we would be.
Then again, the need to build smaller and more reliable electronics did a lot to jump-start the computer revolution -- so we mustn't complain too much!
All of which has nothing to do with CrossOver Office. Which (I'll say it a third and last time, then give up) is just a prepackaged set of Wine configurations.
Dude, think it through. As I said before, CrossOver Office is just Wine pre-configured to support a list of programs. If your program is not on that list, CrossOver Office won't do you any good. Since the program the guy's trying to run is an "industry-specific application" I think it's a safe bet that it's not on the list.
Crossover Office won't help you. It's just Wine pre-configured to support a lot of standard apps. People buy it to save themselves the (severe) headaches of hand-configuring Wine.
All the other choices you mention are ones you absolutely must not consider. Why? Because they defeat your primary purpose. Which is not just to get this one Windows app working. It's to maintain Linux as your primary desktop environment. If keeping Linux supreme in your workplace is your primary goal, then you must find a way to allow your users to run this app under Linux. If you force them to fire up a separate Windows environment just to run one program, you're telling them that Linux can't meet their needs. Eventually, they're going to say to each other, "Why are you using this stupid system that the geeks like, but doesn't run all the programs we use? Why don't we just run Windows?"
But Smalltalk never got anything like the acceptance that Java got. It was just too far away from the way most programmers work. So even though there have been first-rate Smalltalk implementations from the very beginning -- and work on Smalltalk continues to this day -- it's never been a major contender as a programming language.
Java, by contrast, made enough comprimises with C++-style programming to be quickly accepted by professional developers. Perhaps a little too quickly, because Java's reputation for poor performance was firmly established by the horrible VMs and compilers Sun released early on.
So now .NET what people first think of when they think of VMs, because Microsoft has grabbed the ball that Sun dropped. They'll certainly drop it too, but that only makes it even more sad.
It's a little sad that when you raise this issue, you immediately think of .NET. Java was there first. But Sun's early Java implementations actually had pretty severe memory leaks, firmly establishing Java's reputation as a low-performance platform.
Anyway, it's a moot point. All the major browsers are implemented in C++, which doesn't support VM-style memory management. There used to be several Java-based web browser projects, but none of them really got beyond the demo phase.
I know what you're saying: "Bullshit! When I import a Word document into OO, I get a total mess!" But that's not because OO can't parse the data in the Word file. That's because word processor files are full of messy little embedded formatting instructions that are very difficult to exactly translate into another format. It's like tearing down a house, exactly analyzing how the house was put together as you go, and then trying to rebuild the same house with completely different materials. Unless the house is a really simple structure, it's practically impossible to end up with exactly the same house.
Everyone seems to think that using XML instead of binary magically eliminates such formatting issues. Not true. XML is just a means to an end, and that end is content-presentation separation. If you separate all your presentation instructions into a separate stylesheet, then you can impose proper structure on your document and make it app-portable. You don't need XML to do that -- XML just makes it less work, because XML parsing is standardized.
But somebody hacking out a memo or a white paper can't be bothered with issues like that. They just need a document that looks good and is ready for the 2pm meeting. So their document is content and presentation all mixed up. Which isn't going to be app portable, whether the format is binary, RTF, or XML.
Microsoft isn't going to XML because they've suddenly got the open format religion. Microsoft is going to XML because that's the state of the art for data storage and transmission. It helps their apps interact with SOAP servers, XML-based filesystems, XML-based databases, XML-base content-management systems, etc. In theory, these could all be non-Microsoft softwares, but in practice Microsoft will do what they've always done: introduce silly little incompatibilites that will make everybody else jump through hoops if they want to interoperate. The incompatibilities will be easier to identify in XML-based files, but they'll still be there.
The fundamental compatibility problem is Microsoft's arrogant corporate culture that puts getting their way ahead of standardization. Until that changes, no "open format" is going to fix the problem.
My experience with LaCie makes it very unlikely I will buy anything with that label, for any price, regardless of quality. Poor designs, bad warantees, no U.S. tech support.
CRTs are ancient. Not just by virtue of being around since 1897. Even the name harks back to an earlier era of science. They work by virtue of a mysterious thing called "cathode rays". A better term would be "electron beams", but electrons hadn't been discovered when cathode rays were first observed!
Security is always about tradeoffs. If you're that paranoid about password protected access, you shouldn't use it at all.
All of which assumes that current models of geology and radioactive decay are even close to accurate. I don't know enough to have an opinion, but I seem to recall a time when 3 billion was the "official" figure. I kind of resent being "corrected" for citing an number which was valid the last time I read about the topic.
If you'd clean up your source code, maybe you'd get more patches!
I'm taking bets on whether Harlan Ellison will finish "Last Dangerous Visions" before then!
No, in order to qualify as a YE, you have to deny that "billion" is an actual number!
That would require actually reading TFA. Slashdot editors who do that are summarily fired!
Zonk, if you don't word your headlines more carefully, you're just begging people to make silly posts like this one: Earth is still in beta? After 3 billion years?
I agree with you on every point. Unfortunately, EMACS and Vi zealots mostly refuse to acknowledge these issues. Which mostly doesn't matter, except that many of them are also OSS zealots, and their efforts to free us all from the Microsoft Monoculture are badly hampered by their inability to grasp the concept of lockin.
Of course, that's easier said than done. I've been telling myself for years that Vi (or rather Vim, which has pretty much displaced its prototype) is totally obsolete, since its most important design constraints (must work on a time-sharing system over a 300 bps line connected to a primitive dumb terminal) no longer apply. But all the various editors I've tried seem to not be worth the trouble. Though that might have been an excuse...
Lately, I've been playing with jEdit which absolutely demolishes every excuse I have for not switching to it. But every time I face the task of retooling my Vim macros and customizations for jEdit, and retooling my aging brain to use jEdit's interaction paradigm, I suffer a total failure of nerve. Help, I'm locked in and I can't get up!
Not that Bill Joy is more ergonomically aware than Richard Stallman. It's just that when he invented Vi, he had to support the cheapo terminals at UC Berkely, which didn't have screen buffers, programmability, or fancy modifier keys. So he simplified the editing model, and forced the user to maintain state information in wetware. Which make vi rather less sophisticated, but a lot easier to keyboard for.