A friend in middle school did that; they were having fun, sabers flickering from the power lines, and one of them brought his "saber" down in a centered two-handed downstroke above my friend. My friend held his "saber" horizontally to block -- and it would've worked, too, if the descending saber hadn't shattered -- sending a cloud of sharp glass fragments into my friend's face.
So, now that they're concentrating so much effort on the look and feel it must be really solid on the core functionality, like opening a simple MSWord file, making a simple text edit, and saving it back to the same format (so you can return it to the MS person who sent it to you).
This document may contain attributes and information that cannot be saved Microsoft Word 97/2000/XP. Do you want to save your changes using the OpenOffice.org 1.0 Text Document format?
Argh! Great, keep unifying with desktops, but it's still pretty restricted in its ability to interoperate with an existing base of Windows office users. (or at least give a hint as to what "attributes and information" are causing trouble so people can avoid using them)
Re:Salon: News writen by Sophomores...
on
Safe and Insecure?
·
· Score: 2, Informative
Sure, they encourage sharing, and they offer divided billing, but their customers are still liable for whatever traffic they exchange with speakeasy. I don't know if you have the same Terms of Service that I have, but I see this when I log in and poke around. Look down to "responsible" at the end.
Speakeasy's Wireless Sharing Policy
Speakeasy has been an outspoken supporter of Wireless technology and services for quite some time and has one of the most progressive wireless sharing policies in the business.
Wireless networking and publicly shared wireless networks present exciting new opportunities to share information and connectivity resources with one another - we encourage you to explore it!
Speakeasy believes that shared wireless networks are in keeping with our core values of disseminating knowledge, access to information and fostering community, provided this usage does not have an adverse impact on the services of other customers, does not involve any illegal activity and is not otherwise in violation of any aspect of our existing Terms Of Service. Please remember that the Speakeasy account-holder is responsible for all activity originating from their DSL line, even if it is the result of other users on a shared wireless connection.
When I used to work at the LIGO40 meter prototype, the primary laser there put out 4 watts in its primary mode. That mode (frequency or color) was in the visible band, a brilliant green. If an object like a plastic pen crossed the beam, it would immediately start to smoke and melt. We did not experiment with fingers (or eyes!), but it was pretty target-independent.
If one were to have a matchbox-sized battery-powered device that emits four watts of continuous focusable light energy in the visible band, I would call that device a weapon. Or at least a component in one. Even the (yes, fictional) laser rifle desired by the Terminator was a pulsed 40W; ten of your 4W projectors would make a continuous 40W beam. The military name for that weapon would probably be the Force Projector.
The laser was really generating around 30 watts(!), but across a number of frequencies (colors). For the simple task of burning things (or lab workers) that small variation in frequencies wouldn't matter. Of course, this laser required 48000 watts (480 volts at 100 amps), so it wasn't exactly lossless, but it does give a sense that a 4W beam of light isn't exactly minor.
A continuous external feed of energy could, in theory, cause a craft to continue to operate without carrying any fuel. Perhaps one could capture energy from a large radiant light source. If only there were such a thing somewhere near the Earth...
However, if one were using efficient solar cells, one might expect such a ship to be black on the top. The inverted-orca coloring pictured would reflect too much light. Service to Seattle may be erratic, but you'd never have to worry about being forced to take a red-eye.
But, you know, this particular one reeks of vaporware. Ignore them until they demonstrate something useful and allow independent observers to examine it. Move along.
This technique was reasonably popular during my years (early 1990's) at Caltech, which has an earned reputation for overworked undergrads. When stuck on a problem, one would review the content of the problem and consider some general approaches, and then fall asleep. With some practice, this sleep would be immediate and short (30 min). Most of the time, one would wake with a correct sense of how to approach the problem. I have continued to do this since, when I have a lot of math or physics work.
This worked well for mathematics and physics problems when the missing element is which approach to take in solving the problem. Detailed work, like actually doing a proof or derivation, are definitely work for the waking, rational mind, but the choice of an approach is typically more intuitive.
We never knew how this worked. It could have been a semiconscious exploration of the search space, the simple refreshment of a short rest, some distance from the problem that allowed a fresh perspective, or even a placebo. We did not have the resources (esp. time!) to study this effect scientifically. But it did help, and that was our main priority at the time. There may also be other ways to get these benefits; I've heard similar things about meditation, but that's not from personal experience.
Some cautions: if not practiced at short sleeps, or if drastically sleep-deprived, that short sleep could turn into 13 hours; sudden waking seemed to prevent any benefit, so only set an alarm later than the expected waking time; waking can involve a need to scribble down ideas suddenly, so keep a pencil and paper nearby unless you want to re-enact a scene from "Memento".
This concentrated more on scene construction than single-object modeling. It had some very nice aspects. One thing I liked was the use of shadows to specify depth of one object relative to others.
For instance, when an arrow object is placed in the arrow/target scene on that page, it could be at any depth along the camera's line of sight. That's an underconstrained situation, and the system would guess at a reasonable distance for the object. By jotting in a shadow on the ground, it would move the arrow to the position that would match that shadow position.
A well-known need in academia: proven correctness.
Tools to automate much of the work of proving
correctness of program fragments
If the precondition is satisfied, the code fragment is guaranteed to result in a state that satisfies the postcondition.
Tools to automate composition of proven fragments, to prove larger components
if Apre is taken to Apost by A, Bpre to Bpost by B, and Bpre is implied by Apost, then AB takes Apre to Bpost.
Tools to generate examples of failure states
When a proof of correctness for a code fragment fails, some set of initial
states will not be guaranteed to work. By examining that subset of initial
states which aren't guaranteed to work, one can generate test cases and
determine whether the prover needs more axioms or else that the program is
actually incorrect.
Proving correctness is often difficult, but this is largely due to the grunt work involved (which is another source for human error). One
needs good tools to minimize the human effort.
Sure, your program-proving system has to be
correct itself, or else you get nasty bugs, but
that same situation doesn't keep us from using compilers. And this doesn't eliminate all correctness problems, as specifications virtually never come with enough detail to support this process without programmer effort, but it would certainly be useful to have better code-proving systems.
And if anyone knows of available systems that actually provide these tools, by all means let us know!
And/var, and then make/etc/mtab a symlink into one of the writable mounts, and configure syslogd to stop writing to/dev/log, and make xfs stop writing to/usr/lib/X11/fonts, and then make sure the home directories are writeable if you don't want a whole lot of applications to scream and fail, etc.
I've rolled bootable CDs recently, and there's a whole lot of expectation in modern Linux systems that filesystems are mounted read-write. Sure, one can work around them, but it does take a good amount of work to hunt down and make all of the necessary modifications.
It would definitely make remote diagnosis of
problems a lot simpler. Instead of "What does it
say now?" it would be "Just a second; I'll log in
and check it out."
They weren't terrible things, but parts of my company have wanted to do a few things over the years that would be bad for our customers. I've refused to work on them, but always with clearly-presented objections. They've not gone ahead, or have been killed around deployment time.
It actually works better to delay refusal and start with the objections. Those early phases of design will drag out as you work to build consensus on your objection. If you refuse immediately, you lose your involvement, you lose your voice on the matter. Also, you don't want people to start disrespecting and ignoring you for seemingly arbitrary obstructions.
I always start with the explanation of long-term damage to the company, as this is the best way to counter the typical motivation. Someone says that this will increase long-term profits, and you need to point to the way that this is actually an illusion. This approach is valid for the very large fraction of destructive projects that are really trading off long-term success for short-term success.
However, there will be times when the company will actually make greater profits from a questionable practice, or else ignores the arguments in the first bit. This is where the hard personal decisions and possible sacrifice would come in. Yes, if you don't want to work on it, you will have to continue to refuse or else quit. I have not had to escalate to this point. However, if I were to get that far, I expect I would prefer quitting to being fired, and would make it very clear to the other programmers and to senior management why I was leaving.
The keys to any of this working are that you are correct, the management is willing to listen to you, is sensible, and has their own motivation to be reasonable above and beyond the profit motive. If they didn't fit that description, I'd start looking for alternate employment. Finally, I don't find these situations to be a bad sign; only if the company doesn't respond well is the company unhealthy.
802.11 there is OK, but it's hardly as useful as in a cafe or library.
I would greatly prefer that they install the
cell-phone blockers to prevent the now nearly
reliable mid-screening rings. Three different
cellphones went off during one sparsely-attended
movie I watched this weekend.
I also wouldn't appreciate the rest of the
theater turning on backlit LCD displays, tapping away
at interfaces, etc. during a movie.
The best a chemical rocket can do is get up to
speed (burning up all its propellant in the
process) and then drift to its destination, like a
car coasting down the highway with its engine off.
What's needed are space drives that will provide
a constant velocity.
So what's the difference between drifting and moving at a constant velocity? Spaceflight
analysis really shouldn't be done by people who
fail to distinguish between velocity and
acceleration.
I would like a slightly different form of smart board. While I know of one professor who was going
to try to do this, I've not seen anyone actually build one. This would not be for presentations; it would be for derivations and proofs. I mention it mainly
as an example of how 'smart' a whiteboard
could be.
Suppose you have an LCD touchscreen and a
stylus. You write equations to the board, and it
recognizes the symbols. Then you can start
manipulating the symbols, using a set of
mathematical rules (e.g. commutativity of certain
operators). You could circle a term and drag
it to the other side of an equals sign, with
the board
automatically flipping the sign of the term.
Or it could differentiate the two sides of an
equation with respect to some variable.
The device should be able to copy
the equation to the next line, effecting the
changes and verifying their correctness. The
device should allow scrolling off the board,
while recording every operation.
This is clearly a different thing, and not
necessarily too useful for presentations and
lectures. But it would certainly be useful for
research.
I set up some of this to check my thesis work.
I did my M.S. in robotic dynamics. There were
many equations to derive, with symbols with sub-
and superscripts that could easily be confused.
So I set up Mathematica scripts that would apply
rules to my inputs to determine whether they
could be proven from my axioms. It produced TeX
output, with an equals sign if it could verify
the equation, a not-equals sign if it could
disprove it, and the common question-equals for
any equations it couldn't decide. It was easy
to glance at the output and see what lines needed
attention. This was an
effective tool in deriving the correct equations.
The only significant part that I didn't build
was an interactive user interface.
With the recent production of many touchscreen
LCDs in laptops and tablet PCs, this may be a fine
time to explore the handwriting recognition
aspects.
Please read your own citations and call
out the domain of applicability of such comments.
The Berkeley AMPED paper explicitly says that while
"Servers using a single-process event-driven (SPED) architecture can provide excellent performance for cached workloads, where most requested content can be kept in main memory", when the cache cannot all
be held in memory at the web server this ceases to
be true: "On workloads that exceed that capacity of the server cache, servers with multi-process (MP) or multi-threaded (MT) architectures usually perform best."
So they've found that any system that can be
stored in memory at the very front edge of the
serving system tends to be served faster with
their SPED approach. But they've also found that
anything that hits the disk, or hits other slow
services (e.g. back-end databases, transaction
processing) works better in a multithreaded mode.
That's why their new AMPED is a hybrid: it uses the
model that appears to be best for the task. If
you know your server will carry only small, cached
content, then you might ditch any selection
overhead of AMPED by just using a SPED pattern.
But if you're always going to be dealing with
heavyweight services then a MT approach would win.
So please don't slam someone for having used an
approach that is superior in many domains, unless
you at least know that they misused it. Threads
are not uniformly deficient in a web serving environment.
Slashdot Mirror
Well, if it's a comet, it might be called Wolf-Biederman ...
Did they explain why a multifunction device like the HP OfficeJet 4110 won't *scan* unless the printer portion has fresh ink?
This is why I will never buy a multifunction printer/scanner again.
It's amusing that you mention "Forbidden Planet", which is itself a mashup of "The Tempest" (which is in the public domain).
A friend in middle school did that; they were having fun, sabers flickering from the power lines, and one of them brought his "saber" down in a centered two-handed downstroke above my friend. My friend held his "saber" horizontally to block -- and it would've worked, too, if the descending saber hadn't shattered -- sending a cloud of sharp glass fragments into my friend's face.
He did eventually recover.
I'd rather use this elegant solution.
Plus, this hanging one wouldn't try to kill my cat every morning like Clocky would.
So, now that they're concentrating so much effort on the look and feel it must be really solid on the core functionality, like opening a simple MSWord file, making a simple text edit, and saving it back to the same format (so you can return it to the MS person who sent it to you).
Argh! Great, keep unifying with desktops, but it's still pretty restricted in its ability to interoperate with an existing base of Windows office users. (or at least give a hint as to what "attributes and information" are causing trouble so people can avoid using them)
Sure, they encourage sharing, and they offer divided billing, but their customers are still liable for whatever traffic they exchange with speakeasy. I don't know if you have the same Terms of Service that I have, but I see this when I log in and poke around. Look down to "responsible" at the end.
When I used to work at the LIGO 40 meter prototype, the primary laser there put out 4 watts in its primary mode. That mode (frequency or color) was in the visible band, a brilliant green. If an object like a plastic pen crossed the beam, it would immediately start to smoke and melt. We did not experiment with fingers (or eyes!), but it was pretty target-independent.
If one were to have a matchbox-sized battery-powered device that emits four watts of continuous focusable light energy in the visible band, I would call that device a weapon. Or at least a component in one. Even the (yes, fictional) laser rifle desired by the Terminator was a pulsed 40W; ten of your 4W projectors would make a continuous 40W beam. The military name for that weapon would probably be the Force Projector.
The laser was really generating around 30 watts(!), but across a number of frequencies (colors). For the simple task of burning things (or lab workers) that small variation in frequencies wouldn't matter. Of course, this laser required 48000 watts (480 volts at 100 amps), so it wasn't exactly lossless, but it does give a sense that a 4W beam of light isn't exactly minor.
A continuous external feed of energy could, in theory, cause a craft to continue to operate without carrying any fuel. Perhaps one could capture energy from a large radiant light source. If only there were such a thing somewhere near the Earth...
However, if one were using efficient solar cells, one might expect such a ship to be black on the top. The inverted-orca coloring pictured would reflect too much light. Service to Seattle may be erratic, but you'd never have to worry about being forced to take a red-eye.
But, you know, this particular one reeks of vaporware. Ignore them until they demonstrate something useful and allow independent observers to examine it. Move along.
This technique was reasonably popular during my years (early 1990's) at Caltech, which has an earned reputation for overworked undergrads. When stuck on a problem, one would review the content of the problem and consider some general approaches, and then fall asleep. With some practice, this sleep would be immediate and short (30 min). Most of the time, one would wake with a correct sense of how to approach the problem. I have continued to do this since, when I have a lot of math or physics work.
This worked well for mathematics and physics problems when the missing element is which approach to take in solving the problem. Detailed work, like actually doing a proof or derivation, are definitely work for the waking, rational mind, but the choice of an approach is typically more intuitive.
We never knew how this worked. It could have been a semiconscious exploration of the search space, the simple refreshment of a short rest, some distance from the problem that allowed a fresh perspective, or even a placebo. We did not have the resources (esp. time!) to study this effect scientifically. But it did help, and that was our main priority at the time. There may also be other ways to get these benefits; I've heard similar things about meditation, but that's not from personal experience.
Some cautions: if not practiced at short sleeps, or if drastically sleep-deprived, that short sleep could turn into 13 hours; sudden waking seemed to prevent any benefit, so only set an alarm later than the expected waking time; waking can involve a need to scribble down ideas suddenly, so keep a pencil and paper nearby unless you want to re-enact a scene from "Memento".
Sorry, I somehow managed to get a space in that URL.
r ch /sketch/
http://www.cs.brown.edu/research/graphics/resea
In the mid-'90s, researchers at Brown developed Sketch:
r ch /sketch/
http://www.cs.brown.edu/research/graphics/resea
This concentrated more on scene construction than single-object modeling. It had some very nice aspects. One thing I liked was the use of shadows to specify depth of one object relative to others.
For instance, when an arrow object is placed in the arrow/target scene on that page, it could be at any depth along the camera's line of sight. That's an underconstrained situation, and the system would guess at a reasonable distance for the object. By jotting in a shadow on the ground, it would move the arrow to the position that would match that shadow position.
>> before the stock market crash that led to the great depression
> I believe the mogul was Warren Buffett.
Wow, I knew Warren Buffet was getting on in years, but it's quite surprising to learn that he was already a mogul 74 years ago!
(actually, he was born in 1930, the year after the crash)
What great timing! If you liked this article, you might also enjoy "Shattered Glass", in theaters now...
The ethanol-powered fuel cells are the way to go (not methanol). Then you and your gadgets can share the same hip flask. "One for you, one for me"
With a 2 megapixel camera and a 0.15 megapixel display, does anyone else think that PDA makers are concentrating on the wrong features?
A well-known need in academia: proven correctness.
If the precondition is satisfied, the code fragment is guaranteed to result in a state that satisfies the postcondition.
if Apre is taken to Apost by A, Bpre to Bpost by B, and Bpre is implied by Apost, then AB takes Apre to Bpost.
When a proof of correctness for a code fragment fails, some set of initial states will not be guaranteed to work. By examining that subset of initial states which aren't guaranteed to work, one can generate test cases and determine whether the prover needs more axioms or else that the program is actually incorrect.
Proving correctness is often difficult, but this is largely due to the grunt work involved (which is another source for human error). One needs good tools to minimize the human effort.
Sure, your program-proving system has to be correct itself, or else you get nasty bugs, but that same situation doesn't keep us from using compilers. And this doesn't eliminate all correctness problems, as specifications virtually never come with enough detail to support this process without programmer effort, but it would certainly be useful to have better code-proving systems.
And if anyone knows of available systems that actually provide these tools, by all means let us know!
> So, just mount /tmp/ on a ram drive ...
/var, and then make /etc/mtab a symlink into /dev/log, and make xfs stop /usr/lib/X11/fonts, and then make
And
one of the writable mounts, and configure syslogd
to stop writing to
writing to
sure the home directories are writeable if you
don't want a whole lot of applications to scream
and fail, etc.
I've rolled bootable CDs recently, and there's a
whole lot of expectation in modern Linux systems
that filesystems are mounted read-write. Sure,
one can work around them, but it does take a good
amount of work to hunt down and make all of the
necessary modifications.
It would definitely make remote diagnosis of problems a lot simpler. Instead of "What does it say now?" it would be "Just a second; I'll log in and check it out."
I've done this several times.
They weren't terrible things, but parts of my company have wanted to do a few things over the years that would be bad for our customers. I've refused to work on them, but always with clearly-presented objections. They've not gone ahead, or have been killed around deployment time.
It actually works better to delay refusal and start with the objections. Those early phases of design will drag out as you work to build consensus on your objection. If you refuse immediately, you lose your involvement, you lose your voice on the matter. Also, you don't want people to start disrespecting and ignoring you for seemingly arbitrary obstructions.
I always start with the explanation of long-term damage to the company, as this is the best way to counter the typical motivation. Someone says that this will increase long-term profits, and you need to point to the way that this is actually an illusion. This approach is valid for the very large fraction of destructive projects that are really trading off long-term success for short-term success.
However, there will be times when the company will actually make greater profits from a questionable practice, or else ignores the arguments in the first bit. This is where the hard personal decisions and possible sacrifice would come in. Yes, if you don't want to work on it, you will have to continue to refuse or else quit. I have not had to escalate to this point. However, if I were to get that far, I expect I would prefer quitting to being fired, and would make it very clear to the other programmers and to senior management why I was leaving.
The keys to any of this working are that you are correct, the management is willing to listen to you, is sensible, and has their own motivation to be reasonable above and beyond the profit motive. If they didn't fit that description, I'd start looking for alternate employment. Finally, I don't find these situations to be a bad sign; only if the company doesn't respond well is the company unhealthy.
802.11 there is OK, but it's hardly as useful as in a cafe or library.
I would greatly prefer that they install the cell-phone blockers to prevent the now nearly reliable mid-screening rings. Three different cellphones went off during one sparsely-attended movie I watched this weekend.
I also wouldn't appreciate the rest of the theater turning on backlit LCD displays, tapping away at interfaces, etc. during a movie.
So what's the difference between drifting and moving at a constant velocity? Spaceflight analysis really shouldn't be done by people who fail to distinguish between velocity and acceleration.
I would like a slightly different form of smart board. While I know of one professor who was going to try to do this, I've not seen anyone actually build one. This would not be for presentations; it would be for derivations and proofs. I mention it mainly as an example of how 'smart' a whiteboard could be.
Suppose you have an LCD touchscreen and a stylus. You write equations to the board, and it recognizes the symbols. Then you can start manipulating the symbols, using a set of mathematical rules (e.g. commutativity of certain operators). You could circle a term and drag it to the other side of an equals sign, with the board automatically flipping the sign of the term. Or it could differentiate the two sides of an equation with respect to some variable.
The device should be able to copy the equation to the next line, effecting the changes and verifying their correctness. The device should allow scrolling off the board, while recording every operation.
This is clearly a different thing, and not necessarily too useful for presentations and lectures. But it would certainly be useful for research.
I set up some of this to check my thesis work. I did my M.S. in robotic dynamics. There were many equations to derive, with symbols with sub- and superscripts that could easily be confused. So I set up Mathematica scripts that would apply rules to my inputs to determine whether they could be proven from my axioms. It produced TeX output, with an equals sign if it could verify the equation, a not-equals sign if it could disprove it, and the common question-equals for any equations it couldn't decide. It was easy to glance at the output and see what lines needed attention. This was an effective tool in deriving the correct equations. The only significant part that I didn't build was an interactive user interface.
With the recent production of many touchscreen LCDs in laptops and tablet PCs, this may be a fine time to explore the handwriting recognition aspects.
Sorry, that's the Rice AMPED. Berkeley had the SEDA.
Yes, yes, ironic given my exhortation to read sources.
Please read your own citations and call out the domain of applicability of such comments.
The Berkeley AMPED paper explicitly says that while "Servers using a single-process event-driven (SPED) architecture can provide excellent performance for cached workloads, where most requested content can be kept in main memory", when the cache cannot all be held in memory at the web server this ceases to be true: "On workloads that exceed that capacity of the server cache, servers with multi-process (MP) or multi-threaded (MT) architectures usually perform best."
So they've found that any system that can be stored in memory at the very front edge of the serving system tends to be served faster with their SPED approach. But they've also found that anything that hits the disk, or hits other slow services (e.g. back-end databases, transaction processing) works better in a multithreaded mode.
That's why their new AMPED is a hybrid: it uses the model that appears to be best for the task. If you know your server will carry only small, cached content, then you might ditch any selection overhead of AMPED by just using a SPED pattern. But if you're always going to be dealing with heavyweight services then a MT approach would win.
So please don't slam someone for having used an approach that is superior in many domains, unless you at least know that they misused it. Threads are not uniformly deficient in a web serving environment.