...terrorists simply sitting around an airport and blasting planes out of the sky with rockets. That is a hell of a lot more likely than some terrorist trying to sneak on specialized explosive...
Maybe, maybe not. Portable SAMs aren't that easy to come by. The famous truckloads of Stingers and SA-7s that went into Afghanistan are all unusable by now. The batteries in those things are dead by now, and because the battery also contains components needed to run the infrared seeker it's hard to replace. It's not just a matter of splicing in a 12V supply. Also, SAM defence is currently being worked on (systems are already available that are supposed to lure a SAM away from the aircraft it's aimed for), and a SAM launcher isn't really inconspicuous.
Introduction of Apple Lisa: 1983 Introduction of Apple Macintosh: 1984 Introduction of Commodore Amiga: 1985 Source of (some of) the UI ideas in Lisa and Macintosh: Xerox PARC, not Commodore.
Your anECdotal evidence notwithstanding, German highways have an excellent safety record, with fewer deaths per passenger*km than highways in most countries, iirc including the US.
Germany is the only country that still has highways without a speed limit. A few years ago I read an interview with Thomas Bscher (now CEO of Bugatti?). Back then, he used a McLaren F1 for his 400km commute, which he'd routinely do in 2 hours. When the time came to service the car, the car got hooked up to a telephone line so McLaren could read the engine management system remotely. The logs showed speeds of up to 300 km/h on a regular basis, so the company called Bscher, to verify he'd really done those speeds. Most customers never got their cars up to 300 km/h, so McLaren assumed something had to be wrong with the ECU...
France has a 130 km/h limit and is getting increasingly anal about enforcing it.
The USP of the Newton was the way its applications worked together. The ability to write 'lunch John' and have the system guess the time and which person you were referring to is what sets it apart from most information managers. The fact that this feature still is this rare is mindboggling, by the way. What have the world's application developers been doing for the last decade? The future's there for the copying, but instead we get more crap shoveled down our throats.
Somehow I doubt that the ligatures and hyphenation were correct, however.
For all languages supported by Frame, the hyphenation was definitely correct. Ligatures we usually don't bother with. We produce manuals, not novels or typesetting showcases. If the language isn't supported by Frame, we don't use Frame to produce the book. After 10 years of producing manuals, I can count the number of times that has happened on one hand.
FrameMaker has its limtations, sure, I never said it was perfect. Language support is limited to Western, East European and CJK. If you need others, use another tool. On the website for LyX, I find this comment: " Support for writing documents in most European languages" - most? So LyX (or LaTeX) has language limitations as well?
Fortunately, many product manuals can do without Sanskrit and consonant charts. As for the 'only one language' dig: wrong. We've produced loads of multilanguage manuals.
LaTeX has its limitations, too. It has no integrated drawing tools, for instance, so when translating a document that contains images with callouts, you'll have to send the images to the translator separately. In FrameMaker, the callouts can be part of the FM document, which simplifies translation.
You let the developers touch the source files for your manuals? In my experience, that usually leads to things breaking, not to mention that the writer will have to review all of the developers' changes to filter out the Engrish and programmer-speak. Better to let the code monkeys provide their comment in a different format. Developers != good writers, in most cases. PDF is ideal for reviewing: the reviewer can add comments to the PDF, and the writer can easily integrate multiple comment sets into a single PDF so he can view all comments in a single pass. Then the writer decides how to incorporate those comments, as it should be.
If you're going to use FrameMaker, there are loads of output tools available. RoboHelp Frame is easy to use, but not the most flexible in terms of formatting the output. Webworks ePublisher is very flexible, but rather arcane if you go beyond the provided templates.
If you want/need to provide a Word file, use Mif2Go.
I can't stand using finicky, annoying WYSIWYG word processors anymore. LaTeX is simply a better way.
LaTeX may be better than Word, but better than any WYSIWYG word processor? I find that hard to believe. Try using a real WYSIWYG application like FrameMaker. All the consistency of LaTeX, plus a GUI that actually helps you instead of getting in the way.
What's the scope and scale of the manual? If it's a complex piece of software, the manual is probably more than a few pages, which rules out Word. Word tends to choke on long documents.
FrameMaker is a good choice. It was designed specifically for producing large manuals. Unlike Word, it does a good job of separating content from layout, meaning you can concentrate on writing stuff instead of having to fiddle with layout issues. Its main drawback is limited support of non-Western languages. If you need to translate your documents to Thai or Arabic, FrameMaker isn't the best choice. With products like Webworks ePublisher or Robohelp, you can publish to various HTML and other online formats, including context sensitive help.
There are other packages geared towards producing large manuals. AuthorIT is one I can recommend. Unlike FrmaeMaker, it supports Unicode. It's built on top of a database, meaning you have document management facilities which come in handy if you're writing lots of related manuals, reusing text etc. It also offers export to Word, PDF and online formats.
Others I haven't worked with. Some have recommended LaTeX. My experience with this is limited. You really need a graphical front end to flatten the learning curve. Changing the layout of your output isn't straightforward either. I don't know how well OpenOffice handles long documents. But the way it's built to mimic Word makes me wary. Does it have a way to consistently apply styles?
From the wording of Saulo's post, I guess he's a developer. No offence, but few developers are good writers. For one thing, many developers (and engineers in general) have a hard time putting themselves in the customer's shoes. This leads to manuals that omit lots of information that's obvious to the engineer, but not to the customer. You may be better off hiring a technical writer instead.
(I write manuals for a living. I mainly use FrameMaker and AuthorIT. )
This argument is based on an entirely specious argument, that vinyl is supposedly "analog" while CDs are "digital". Well, repeat after me: "THE UNIVERSE IS QUANTIZED".
Uh, no. Vinyl can be better than CD, but the reasons you mention have nothing to do with it. - 16-bit quantization was the upper limit of the commercially viable when CD was designed. Today, we know that 24-bit systems are audibly better, so clearly our ears are more accurate than 16-bit encoding can reproduce. - 20 kHz may be the upper limit of human hearing, but that's only when you consider a 20 kHz sinus. Harmonics above 20 kHz do seem to play a role in our perceiving music as 'natural'. - Nyquist sampling means that at the upper limit of the spectrum, phase errors can be quite large. You need a higher sampling frequency.
Yes, analog systems have problems with noise and distortion. But digital systems aren't free from distortion either. Crossover distortion can be a problem, clock jitter, etc.
And as for the "supposedly analog" cheap shot: Yes, vinyl is discrete at the molecular level. Working out how many orders of magnitude lower this level is than the 2^16 resolution of a CD, is left as an exercise for the reader. Wake me up when CDs sample to Avogadro's number of discrete levels.
Slashdot Mirror
...terrorists simply sitting around an airport and blasting planes out of the sky with rockets. That is a hell of a lot more likely than some terrorist trying to sneak on specialized explosive...
Maybe, maybe not. Portable SAMs aren't that easy to come by. The famous truckloads of Stingers and SA-7s that went into Afghanistan are all unusable by now. The batteries in those things are dead by now, and because the battery also contains components needed to run the infrared seeker it's hard to replace. It's not just a matter of splicing in a 12V supply. Also, SAM defence is currently being worked on (systems are already available that are supposed to lure a SAM away from the aircraft it's aimed for), and a SAM launcher isn't really inconspicuous.
Introduction of Apple Lisa: 1983
Introduction of Apple Macintosh: 1984
Introduction of Commodore Amiga: 1985
Source of (some of) the UI ideas in Lisa and Macintosh: Xerox PARC, not Commodore.
Right now the cost of power is remaking the landscape of the data center industry.
What's next? Outsourcing to Canada to profit from lower ambient temperatures (=less cooling required)?
Those democrats went and treated it like a truck
In all fairness, that's an easy mistake to make...
Please. The middle is, by definition, not an "end".
(/usage nazi)
StrategyPage runs a prediction market on geopolitical events, with a similarly high success percentage.
Your anECdotal evidence notwithstanding, German highways have an excellent safety record, with fewer deaths per passenger*km than highways in most countries, iirc including the US.
Germany is the only country that still has highways without a speed limit. A few years ago I read an interview with Thomas Bscher (now CEO of Bugatti?). Back then, he used a McLaren F1 for his 400km commute, which he'd routinely do in 2 hours. When the time came to service the car, the car got hooked up to a telephone line so McLaren could read the engine management system remotely. The logs showed speeds of up to 300 km/h on a regular basis, so the company called Bscher, to verify he'd really done those speeds. Most customers never got their cars up to 300 km/h, so McLaren assumed something had to be wrong with the ECU...
France has a 130 km/h limit and is getting increasingly anal about enforcing it.
Old adage: this is the internet, where men are men, women are men and 16-yo girls are FBI agents.
The USP of the Newton was the way its applications worked together. The ability to write 'lunch John' and have the system guess the time and which person you were referring to is what sets it apart from most information managers.
The fact that this feature still is this rare is mindboggling, by the way. What have the world's application developers been doing for the last decade? The future's there for the copying, but instead we get more crap shoveled down our throats.
Am I the only one who was disappointed when it didn't turn out to be something that can emulate a galaxy?
I would LOVE to use this system for dealing with photographs
Aperture lets you do something like this: you can arbitrarily arrange photos on a workspace (light table).
Apple worked on things like piles in the early '90s.
It's from a Calvin and Hobbes cartoon.
Somehow I doubt that the ligatures and hyphenation were correct, however.
For all languages supported by Frame, the hyphenation was definitely correct. Ligatures we usually don't bother with. We produce manuals, not novels or typesetting showcases.
If the language isn't supported by Frame, we don't use Frame to produce the book. After 10 years of producing manuals, I can count the number of times that has happened on one hand.
FrameMaker has its limtations, sure, I never said it was perfect. Language support is limited to Western, East European and CJK. If you need others, use another tool.
On the website for LyX, I find this comment: " Support for writing documents in most European languages" - most? So LyX (or LaTeX) has language limitations as well?
Fortunately, many product manuals can do without Sanskrit and consonant charts.
As for the 'only one language' dig: wrong. We've produced loads of multilanguage manuals.
LaTeX has its limitations, too. It has no integrated drawing tools, for instance, so when translating a document that contains images with callouts, you'll have to send the images to the translator separately. In FrameMaker, the callouts can be part of the FM document, which simplifies translation.
You let the developers touch the source files for your manuals? In my experience, that usually leads to things breaking, not to mention that the writer will have to review all of the developers' changes to filter out the Engrish and programmer-speak. Better to let the code monkeys provide their comment in a different format. Developers != good writers, in most cases.
PDF is ideal for reviewing: the reviewer can add comments to the PDF, and the writer can easily integrate multiple comment sets into a single PDF so he can view all comments in a single pass. Then the writer decides how to incorporate those comments, as it should be.
If you're going to use FrameMaker, there are loads of output tools available. RoboHelp Frame is easy to use, but not the most flexible in terms of formatting the output. Webworks ePublisher is very flexible, but rather arcane if you go beyond the provided templates.
If you want/need to provide a Word file, use Mif2Go.
I can't stand using finicky, annoying WYSIWYG word processors anymore. LaTeX is simply a better way.
LaTeX may be better than Word, but better than any WYSIWYG word processor? I find that hard to believe. Try using a real WYSIWYG application like FrameMaker. All the consistency of LaTeX, plus a GUI that actually helps you instead of getting in the way.
What's the scope and scale of the manual? If it's a complex piece of software, the manual is probably more than a few pages, which rules out Word. Word tends to choke on long documents.
FrameMaker is a good choice. It was designed specifically for producing large manuals. Unlike Word, it does a good job of separating content from layout, meaning you can concentrate on writing stuff instead of having to fiddle with layout issues. Its main drawback is limited support of non-Western languages. If you need to translate your documents to Thai or Arabic, FrameMaker isn't the best choice. With products like Webworks ePublisher or Robohelp, you can publish to various HTML and other online formats, including context sensitive help.
There are other packages geared towards producing large manuals. AuthorIT is one I can recommend. Unlike FrmaeMaker, it supports Unicode. It's built on top of a database, meaning you have document management facilities which come in handy if you're writing lots of related manuals, reusing text etc. It also offers export to Word, PDF and online formats.
Others I haven't worked with.
Some have recommended LaTeX. My experience with this is limited. You really need a graphical front end to flatten the learning curve. Changing the layout of your output isn't straightforward either.
I don't know how well OpenOffice handles long documents. But the way it's built to mimic Word makes me wary. Does it have a way to consistently apply styles?
From the wording of Saulo's post, I guess he's a developer. No offence, but few developers are good writers. For one thing, many developers (and engineers in general) have a hard time putting themselves in the customer's shoes. This leads to manuals that omit lots of information that's obvious to the engineer, but not to the customer. You may be better off hiring a technical writer instead.
(I write manuals for a living. I mainly use FrameMaker and AuthorIT. )
For a moment I thought they were using actual jet engines to cool the server, but noooooo, they had to go for boring ol' electric fans instead.
[insert rant about misleading summary]
Obviously they're worried about the copyright implications of someone running a typing farm with an infinite number of monkeys.
One disk to 0wn them all?
This argument is based on an entirely specious argument, that vinyl is supposedly "analog" while CDs are "digital". Well, repeat after me: "THE UNIVERSE IS QUANTIZED".
Uh, no. Vinyl can be better than CD, but the reasons you mention have nothing to do with it.
- 16-bit quantization was the upper limit of the commercially viable when CD was designed. Today, we know that 24-bit systems are audibly better, so clearly our ears are more accurate than 16-bit encoding can reproduce.
- 20 kHz may be the upper limit of human hearing, but that's only when you consider a 20 kHz sinus. Harmonics above 20 kHz do seem to play a role in our perceiving music as 'natural'.
- Nyquist sampling means that at the upper limit of the spectrum, phase errors can be quite large. You need a higher sampling frequency.
Yes, analog systems have problems with noise and distortion. But digital systems aren't free from distortion either. Crossover distortion can be a problem, clock jitter, etc.
And as for the "supposedly analog" cheap shot: Yes, vinyl is discrete at the molecular level. Working out how many orders of magnitude lower this level is than the 2^16 resolution of a CD, is left as an exercise for the reader. Wake me up when CDs sample to Avogadro's number of discrete levels.
So they stuck an MG badge on, and installed a V8?