Streaming, for me, generally equals lousy playback. Stuttering, taking lots of time to resynchronize when you skip back or (worse) forward. Usability is sacrificed in an effort by the broadcaster to retain control.
The photo tour has one of the worst interfaces I've seen for viewing photos. Hiding half of the photo caption by default? Who comes up with this idiocy?
One small redeeming feature is that they haven't hijacked the right-click with a bloody Lightbox script.
The RTOS may not be needed for image processing, but I'll bet it's handy when driving, or running other mechanical aspects. And once you have an RTOS for those tasks, it'd be silly to add another OS for the non-time-critical tasks.
First, this is first such geek driven museum I know.
You must have never been to the UK. The place is full of geek-driven musea. From coal mines to aircraft factories to Bletchley Park, all can be visited and all are created and run by geeks of various flavours. The same goes for the rest of Europe, though to a lesser extent IMO.
To achieve 1g through rotation (at a speed low enough that you don't get adverse effects) you need a radius of 225 m, so the two spacecraft would be half a km apart. That would make moving between the two a pain: it means either a spacewalk or a rigid tunnel between the two, and you'd be moving against gravity - a half-km climb is no picnic. You'd be better off making one of the spacecraft a dumb weight with maybe an engine cluster on it for maneuvering.
Don't put all of your eggs in one basket. Make backups of all of your data and ship the backups differently. Take them with you if possible, but checked luggage is not foolproof either, and if you put them in your carry-on luggage you may run afoul of the TSA or its local equivalent.
My company recently migrated to a computer-based phone system.
1. Handsets are much preferable to headsets, if you use the phone only occasionally. I went from *pick up the handset* to a. don the headset, trying not to snag the cable on the stuff on my desk, notably including a mug of tea. b. hunt down the pop-up with the Answer button c. plug in the headset leads because I forgot to do that when I came in d. hope the other party hasn't given up yet.
2. Don't buy the Counterpath Bria product. It chops up your conversations into little bits, and throws away packets randomly. It's bloody awful. The UI is crap, too.
3. it is possible to do IP telephony right. My home phone connects to a 42Networks DRG device which connects to the fiber interface. Sound quality is as good as POTS, and no problems with lag.
In 1972, Soviet physicists at a nuclear research facility near Lake Baikal in Siberia accidentally discovered a reaction for turning lead into gold when they found some of the lead shielding of an experimental reactor had changed to gold
There are a couple of approaches to software documentation. 1. Descriptive (broad focus). Explain to the user what the program is for. Explain the concepts you use. Why do things work as they do?
2. Task oriented. Explain to the user how to perform tasks, e.g. How to set up a compound interest calculation in a spreadsheet. This pulls different elements of the UI together and puts them in context. Useful for the novice, but always lacks some detail the advanced user needs. Skip the trivial ones, depending on your audience.
3. Descriptive with a narrow focus. Sescribe what each element of the user interface does. Helpful as a reference, but not much use to a novice. Man pages are like this.
You'll find that a good manual combines all three approaches (in the above order).
Start writing the manual as early as possible. Use it as part of the software specification process. Then compare the manual and spec to the program: does it work as advertised? If you find that a task is hard to explain or contains more steps than necessary, it's time to improve the user interface.
Involve non-programmers in the manual writing and testing process. They look at the software differently to a programmer. As the creator of a program, you take lots of things for granted that are non-obvious to a user. Find out what these are and either explain them in the manual or (better) redesign your program so you won't need to explain as much.
If you do this as you described, you're in danger of ending up with a book structure more convoluted than the plot of Lost. The information may all be there, but good luck trying to find anything.
Basically, all soundproofing is about weight. More weight=less noise gets through. To reduce the noise coming in through the windows you need to increase the thickness of the panes or their number. Double or triple glazing, or even two double-glazed panes in series with an air gap of ~15 cm in between. You'll also need to look at the window frames. Old steel or aluminium frames are excellent sound conductors.
You can go pretty far with this; my father did some consulting on a housing project near an air force base. They managed to get sufficient soundproofing that living next to F-16s taking off wasn't aggravating any more, but they spent as much on the soundproofing as the houses had cost to build.
Information being published for a specific platform only is a deplorable development. In the PC era this would have been published as PDF and everyone could read it. These days, the desire to monetize information prompts publishers to package information as an application, excluding everyone who doesn't have the targeted platform.
This was bad enough when people repackaged a website as an app: one could just access the website instead. But books shouldn't be platform-specific.
You'd have to move it from its current inclination of ~51 degrees to about 23deg. WAG and I'm not a rocket scientist: 51-23=28, sin(28)=0.47 so you'd have to do a delta-V of about 0.47x orbital velocity which is 12000 km/h applied to 100 tons. A Space Shuttle burns ~1900 tons of fuel to get 100 tons up to 25000 km/h, so call it 1000 tons of fuel to shift the ISS.
LEDs and CFLs are far more resilient than incandescents. Knock over an incandescent, and it's sure to break. CFLs, not so much. They also survive a move just fine with minimal precautions.
The Swiss claim that the design is theirs and dates from 1994 is ludicrous.
Here's a Dutch national railways clock form 1977 which differs only in minor details. There are others which are so similar that the 1994 design can only be called an evolution.
"high pressure", sure, but I don't buy that ordinary bathtubs are produced with pressures an order of magnitude higher than the one-off highest-pressure-in-the-world forge can generate.
Slashdot Mirror
Streaming, for me, generally equals lousy playback. Stuttering, taking lots of time to resynchronize when you skip back or (worse) forward. Usability is sacrificed in an effort by the broadcaster to retain control.
blog entry summarizing the designs shown so far
The /. blog also promises a discussion of the logos when we've seen all of them.
The photo tour has one of the worst interfaces I've seen for viewing photos. Hiding half of the photo caption by default? Who comes up with this idiocy?
One small redeeming feature is that they haven't hijacked the right-click with a bloody Lightbox script.
The future? Color-coded piping has been used since the dawn of the Industrial Revolution.
1 trillion miles = 0.17 lightyears.
The RTOS may not be needed for image processing, but I'll bet it's handy when driving, or running other mechanical aspects.
And once you have an RTOS for those tasks, it'd be silly to add another OS for the non-time-critical tasks.
If not SATA, then what interface do they use?
First, this is first such geek driven museum I know.
You must have never been to the UK. The place is full of geek-driven musea. From coal mines to aircraft factories to Bletchley Park, all can be visited and all are created and run by geeks of various flavours. The same goes for the rest of Europe, though to a lesser extent IMO.
To achieve 1g through rotation (at a speed low enough that you don't get adverse effects) you need a radius of 225 m, so the two spacecraft would be half a km apart. That would make moving between the two a pain: it means either a spacewalk or a rigid tunnel between the two, and you'd be moving against gravity - a half-km climb is no picnic. You'd be better off making one of the spacecraft a dumb weight with maybe an engine cluster on it for maneuvering.
Don't put all of your eggs in one basket. Make backups of all of your data and ship the backups differently. Take them with you if possible, but checked luggage is not foolproof either, and if you put them in your carry-on luggage you may run afoul of the TSA or its local equivalent.
My company recently migrated to a computer-based phone system.
1. Handsets are much preferable to headsets, if you use the phone only occasionally.
I went from *pick up the handset* to
a. don the headset, trying not to snag the cable on the stuff on my desk, notably including a mug of tea.
b. hunt down the pop-up with the Answer button
c. plug in the headset leads because I forgot to do that when I came in
d. hope the other party hasn't given up yet.
2. Don't buy the Counterpath Bria product. It chops up your conversations into little bits, and throws away packets randomly. It's bloody awful. The UI is crap, too.
3. it is possible to do IP telephony right. My home phone connects to a 42Networks DRG device which connects to the fiber interface. Sound quality is as good as POTS, and no problems with lag.
There are plenty of people (including schools) doing that, and one does not preclude the other.
I suppose you could define a cyclotron as a nuclear reactor, but thatâ(TM)s rather unusual.
A cyclotron is a circular particle accelerator, not a nuclear reactor.
In 1972, Soviet physicists at a nuclear research facility near Lake Baikal in Siberia accidentally discovered a reaction for turning lead into gold when they found some of the lead shielding of an experimental reactor had changed to gold
There are a couple of approaches to software documentation.
1. Descriptive (broad focus). Explain to the user what the program is for. Explain the concepts you use. Why do things work as they do?
2. Task oriented. Explain to the user how to perform tasks, e.g. How to set up a compound interest calculation in a spreadsheet. This pulls different elements of the UI together and puts them in context. Useful for the novice, but always lacks some detail the advanced user needs.
Skip the trivial ones, depending on your audience.
3. Descriptive with a narrow focus. Sescribe what each element of the user interface does. Helpful as a reference, but not much use to a novice. Man pages are like this.
You'll find that a good manual combines all three approaches (in the above order).
Start writing the manual as early as possible. Use it as part of the software specification process. Then compare the manual and spec to the program: does it work as advertised? If you find that a task is hard to explain or contains more steps than necessary, it's time to improve the user interface.
Involve non-programmers in the manual writing and testing process. They look at the software differently to a programmer. As the creator of a program, you take lots of things for granted that are non-obvious to a user. Find out what these are and either explain them in the manual or (better) redesign your program so you won't need to explain as much.
hackertourist
(technical writer)
If you do this as you described, you're in danger of ending up with a book structure more convoluted than the plot of Lost. The information may all be there, but good luck trying to find anything.
Basically, all soundproofing is about weight. More weight=less noise gets through. To reduce the noise coming in through the windows you need to increase the thickness of the panes or their number. Double or triple glazing, or even two double-glazed panes in series with an air gap of ~15 cm in between. You'll also need to look at the window frames. Old steel or aluminium frames are excellent sound conductors.
You can go pretty far with this; my father did some consulting on a housing project near an air force base. They managed to get sufficient soundproofing that living next to F-16s taking off wasn't aggravating any more, but they spent as much on the soundproofing as the houses had cost to build.
Information being published for a specific platform only is a deplorable development. In the PC era this would have been published as PDF and everyone could read it. These days, the desire to monetize information prompts publishers to package information as an application, excluding everyone who doesn't have the targeted platform.
This was bad enough when people repackaged a website as an app: one could just access the website instead. But books shouldn't be platform-specific.
You'd have to move it from its current inclination of ~51 degrees to about 23deg.
WAG and I'm not a rocket scientist: 51-23=28, sin(28)=0.47 so you'd have to do a delta-V of about 0.47x orbital velocity which is 12000 km/h applied to 100 tons. A Space Shuttle burns ~1900 tons of fuel to get 100 tons up to 25000 km/h, so call it 1000 tons of fuel to shift the ISS.
If I'm not mistaken, ISS is in the wrong orbital plane for planetary missions, so you'd waste a lot of fuel.
LEDs and CFLs are far more resilient than incandescents. Knock over an incandescent, and it's sure to break. CFLs, not so much. They also survive a move just fine with minimal precautions.
Um, yes. I copied the wrong date from this article.
The Swiss claim that the design is theirs and dates from 1994 is ludicrous.
Here's a Dutch national railways clock form 1977 which differs only in minor details. There are others which are so similar that the 1994 design can only be called an evolution.
"high pressure", sure, but I don't buy that ordinary bathtubs are produced with pressures an order of magnitude higher than the one-off highest-pressure-in-the-world forge can generate.