Just last night I finally dpkg --purged it from my system,
for the first time in all these years. Of course
that failed: who would ever have tested it? I had
to clean up by hand.
Re:I have a first-generation Yopy
on
YOPY Arrives
·
· Score: 1
Some AC wrote, "I'm gonna go out on a limb here and assume that you're still unemployed. Just a hunch."
Misery looking for company? Too bad.
Good luck, and try to forget Perl.
I have a first-generation Yopy
on
YOPY Arrives
·
· Score: 5, Interesting
I fooled with my first-generation Yopy for quite a while while
I was unemployed.
I haven't touched it in a year, because Gmate never released
source for anything but the kernel. Worse, their web site
had a place to upload things, but anything they didn't like,
(like my cool USB
base station mod, evidently [see the serial number?])
they just tossed, without a reply -- the upload would just
vanish into the ether. (I uploaded three times just to be
sure it was deliberate.)
It appears they wanted people to write applications,
but not to fool with the hardware or kernel.
I hope they have got less contemptuous of hackers in days
since. At this point I would be a lot more likely to order
one of those Japan-only Zauruses.
The best way to prepare for a GRE in Computer Science
is to study computer science. A variety of
four-year programs are offered at hundreds of universities
around the world. Apply early and you might get a
scholarship.
Courses in "Microsoft Word2000" probably will be a bit off
the mark. You might have to study some algebra and maybe
even some literature (if you don't choose University of
Phoenix, that is).
The battery life for these things will be about three minutes.
Assuming that by the time the networks get built we
can use fuel-cell batteries, then the problem will be
heat build-up. Can you imagine a phone with a fan?
Heat pumps are little help, because they can only move
heat from inside to the case, and you can't have
the phone getting too hot to hold. "Are you happy to
see me, or is that a 4G phone in your pocket?"
I suppose ice fisherman could use them to keep their
hands warm.
Before these things could become practical we would
need asynchronous-logic chips or spin-coupled logic,
both over a decade off.
The days of defrauding investors are far from over.
It doesn't much matter what you can do with an
inkjet printer. You won't get anywhere close to
what is being done professionally, in mass
production. Syria has been printing an
estimated $20 billion/year, year after year, for
a decade. How much is that? You can fit $2M in
a briefcase. That's 10,000 briefcases full of
bundles of cash, each year. They have to launder
30 briefcases full every day.
The fakes are indistinguishable from the real thing,
even by experts. (No surprise, they're made by experts.)
Maybe Syria has a harder time, now, disposing
of them, with its smuggling routes through Iraq
interfered with. (Closed? You must be kidding.)
Who knows how much is being printed in Russia?
Dollars are very popular there.
It didn't take long at all to start copying the
new bills, which is why the U.S. is going to another
design already.
You probably have some Syrian bills in your pocket
right now. Take a look and see if you can spot them.
Meanwhile the Treasury is harrassing an artist, J.S.Boggs,
for drawing funny money by hand and exchanging it for face
value. Your tax "dollars" at work.
A swamp cooler will only work if it's hot but not
very humid. Here in Boston, for example, it would only make
things worse. Note that you can't leave loose papers lying
around with a swamp cooler running -- it's like a hurricane
in the house.
A ceiling fan makes your air conditioner work much better.
One thing to look for in an air conditioner is the ability to
suck in a bit of its air from outside, instead of just
recirculating inside air or (with the lever pulled) blowing
some inside air out. (Why you would want to do the latter
mystifies me, but that's what they do.) Sucking in some outside air helps push some of the cold air into other rooms.
Some ACs can be configured as heat pumps, too, so that when it
turns cold they can heat the room, for much less than the cost
of running an electric radiant heater, and maybe for less than
gas heat, these days. As heat pumps, they cool off the outside air and blow inside air past their hot condenser
coils.
Live on the ground floor in summer, the top floor in winter.
Imagine my surprise at finding that Slashdot got something
right: forii wrote that a "bottle of Pepto-Bismol contains one decay event" every 36 hours, and it does! Those
alpha particles can't get through the glass.
Not only that, he never said "it's" when he meant "its".
My favorite element, by the way, is Osmium. It sublimates
dreadfully toxic fumes from a solid state at room temperature,
and nobody knows exactly what its specific gravity is, nor
whether it or Iridium is the heaviest element.
My favorite recommendations for the past few years
have been "Arctic Dreams" by Barry Lopez, and
"Guns, Germs, and Steel", by Jared Diamond.
The latter presents a very readable summary of what
is perhaps the first rigorous application of the
scientific method to history. Since it's the first,
he started by answering the big questions of the
past thirteen thousand years. Essentially: how did
Eurasians come to own the world? He knows, and now
I do.
The former is a tour de force covering all aspects of
northern experience, from early exploration to detailed
descriptions of the critters who survive there, and how.
I just open it anywhere, now, and start reading, and am
always captivated. The maps alone bring delight.
I haven't seen many C or C++ programs where I needed to
pass a -Xmx option. When I click on a desktop icon for
a Java program, does it have to pop up a dialog box to
ask me to estimate the memory it should use? If not, how
does it know what other programs I am running that also
use or might use memory? It seems as if the Java program
had better be the only program running on the machine.
Many of us like to run more than one program at a time.
We like to call that multi-tasking. (Maybe it's
silly, these days, to use one computer for more than one
thing, but sometimes we like to run more than one program
to do even just one thing. It might be thought of as an
alternative to threading, which tends to introduce
otherwise unnecessary complexity.)
The better JIT runtimes run bytecodes for
most of the code, and compile only the more heavily-used
functions to machine code. They collect statistics on
which functions and loops are (re-)entered most often, and compile them. The clever ones don't optimize the first time, but only
optimize the ones that still take the most time. As a result,
the JIT compiler, the bytecode interpreter, and its
instrumentation continue to compete for L2 and/or L3 cache
long into the runtime of a program.
JIT compilers are heavily constrained in the degree of
optimization they can afford to apply because they are
running when the program itself is supposed to be running.
Also, since they are not operating on source code, much
of the context is lost by the time they get a chance to
operate. Bytecodes are not very expressive of programmer
intent.
Sagely, Oswald asks, "how do we explain languages like
O'Caml?"
Or certain Lisp implementations, likewise. There are
several answers to this.
First, when performance matters, O'Caml and Lisp are
typically compiled not to bytecodes, but to native code.
They can often be optimized rather better than C or C++
because they do not cater to pointer abuses, and because
their compilers are written in a language better suited to
writing optimizers than C is. Thus, there's no analog to
the typical JVM problems of data and code pages unshareable
among processes, and no cache pressure from a JIT compiler
or its instrumentation and redundant code representations,
and some overhead may be played off against better
optimization.
Second, I gather that O'Caml makes it easier to avoid
abusing GCed memory, so you can often ensure that inner
loops don't generate garbage and end up with allocations
walking the address space. (Disclaimer: I haven't used
O'Caml industrially.)
Third, it is very easy, when writing O'Caml or Lisp, to run
afoul of the same GC problems. Thus, serious programs
written in O'Caml, such as Unison, must have had special
attention paid to avoiding GC-induced problems. The QPX
airline fare search system, written in Common Lisp and used
on Orbitz and Continental Airlines sites -- perhaps the most
heavily used industrial Lisp application in existence --
never GCs. It calls out to a huge C++ library for
anything that needs dynamic allocation or floating-point
operations.
It's possible to make Java programs go fast, it's just
very hard. Compile them to native code with GCJ, turn
off runtime checks, and keep the garbage collector and
anything that generates garbage under a gimlet eye, and
you may get performance comparable to C++. I happen to
find it more satisfying to write in C++. Maybe I care
more about performance than most, and prefer to work on
programs where it matters more. When performance and
type-safety don't matter much, I use Python.
Java has always been naturally slow. Like all
traditionally slow languages, heroic measures have been
taken to attack the problems, and most of the bottlenecks
have been looked into. Bytecodes get compiled to native
code, garbage-collectors get increasingly clever. Still
the programs are way too slow. Why?
One of the reasons is that interactions with caches are
hard to model, making it hard to know what to do to
minimize problems. Caching is, inherently, a deal with
the devil: you get speed but lose understanding.
Sometimes you lose the speed too. Even when you
understand, there's not much you can do. Sometimes
complicated stuff is inherently expensive.
When I say caching,
I mean not just CPU caches of RAM, but also RAM caches of
(potentially swapped-out) process space. If you allow a
naive garbage-collector to operate freely, it will
happily consume the entire address space available,
typically the sum of available RAM and swap space, before
garbage-collecting, so the process will run not from RAM
but from swap. When it garbage-collects, too, it has to
walk a lot of that memory, and swap it all in.
Just running "ulimit -d" in the shell where the java (or
other GC-language) program runs can help a lot. It will
GC a lot more often, but if nothing is swapped out, the GC
happens a lot faster, and the program's regular execution doesn't have to touch swapped-out pages. You have
to know a lot about the program and the data it uses to
guess the right ulimit value, and if you guess wrong the
program fails, but a thousand-fold speed improvement earns
a lot of forgiveness.
Did you really believe garbage collection
would mean you don't have to know about memory management?
It makes memory management harder,
because the problem remains but there's less you can do
about it. (For trivial programs it doesn't matter.
If you only write trivial programs, though, you might
as well find some other job.)
There's a similar effect with the CPU cache and RAM.
Ideally you want the program code and the data it
operates on all to live in cache, because touching
the RAM takes 100 times as long at touching cache.
With bytecodes, you have a lot more "cache pressure"
-- you have the bytecodes themselves, the just-in-time
compiler, and the native code it generates. At the
same time, since your memory manager generally can't
re-use memory that you just freed, it allocates other
memory that, when touched, pushes out something
else that was useful (such as program code).
The result is that no matter how clever the JVM is,
there's not much it can do to get the performance of
real programs close to optimal, or even within a
pleasing fraction of equivalent C++ code. This
despite all the toy benchmarks that seem to prove
otherwise, and which carefully avoid all these
real-world problems.
Of all the promised features of Java (like Lisp before
it and C# after it), we're left with the sole remaining
feature, that its virtual machine specifies precisely
(or abstracts away) enough details of the runtime
environment that the code is more portable than a
faster native implementation, and the code might get
written faster for the author having avoided thinking
about details that affect performance.
The sole saving grace is that most programs don't
have much need to run very fast anyway, or if they
do it's hard to prove that they ought to run faster.
Most people take what they get without complaining,
or without complaining to anybody who cares, or
without doing anything to make whoever is responsible
uncomfortable enough to have to do anything
differently. A whole generation trained to accept
programs that crash daily or hourly is thrilled to find
a program whose biggest problem is that they suspect it
might be sluggish.
Free operating systems run on all the others; obviously
that's the real reason GameCube is in decline. The solution
is clear: Nintendo needs to release a Linux port! (A NetBSD
port will appear, as if by magic, a few weeks after.)
It will be fun to run it under the gCubix GB emulator that
runs on Linux.
If writing "an app that runs as fast as it can while being
stable... cannot be done in C++", then it can't be done at all. Of course, Mozilla isn't written in C++, it's written
partly in slightly-extended C (like the C with Classes
of the mid-'80s), and largely in XUL, a scripting language.
(Imagine, an Anonymous Coward demonstrating bone-crushing
ignorance. What next, flying mallards? Swimming trout?)
There's no reason for the X wire protocol to be
"thread-safe" (i.e. atomic/transactional). There's
not even any need to use locks in Xlib.
A multithreaded program may simply open several
connections to the X server, and operate independent
UIs. One thread might operate a display window,
while another operates a dialog box or progress
bar. As far as X is concerned, it's talking to
different programs.
Don't go looking for complicated solutions when
simple ones are right at hand.
Slashdot Mirror
Just last night I finally dpkg --purged it from my system, for the first time in all these years. Of course that failed: who would ever have tested it? I had to clean up by hand.
Misery looking for company? Too bad.
Good luck, and try to forget Perl.
I haven't touched it in a year, because Gmate never released source for anything but the kernel. Worse, their web site had a place to upload things, but anything they didn't like, (like my cool USB base station mod, evidently [see the serial number?]) they just tossed, without a reply -- the upload would just vanish into the ether. (I uploaded three times just to be sure it was deliberate.)
It appears they wanted people to write applications, but not to fool with the hardware or kernel.
I hope they have got less contemptuous of hackers in days since. At this point I would be a lot more likely to order one of those Japan-only Zauruses.
Courses in "Microsoft Word2000" probably will be a bit off the mark. You might have to study some algebra and maybe even some literature (if you don't choose University of Phoenix, that is).
The Iraq invasion wasn't really about oil, or even about euros.
The Supreme Court didn't really prevent Florida from counting its votes for fear that the candidate it had chosen to appoint wouldn't get in.
That big tax cut really is meant, and expected, to stimulate the economy.
That face on Mars really was carved by space monkeys.
Run some benchmarks. Those machines are about equivalent for most work. It's partly because Athlons rock, but more because P4s suck.
YMMV.
Assuming that by the time the networks get built we can use fuel-cell batteries, then the problem will be heat build-up. Can you imagine a phone with a fan? Heat pumps are little help, because they can only move heat from inside to the case, and you can't have the phone getting too hot to hold. "Are you happy to see me, or is that a 4G phone in your pocket?" I suppose ice fisherman could use them to keep their hands warm.
Before these things could become practical we would need asynchronous-logic chips or spin-coupled logic, both over a decade off.
The days of defrauding investors are far from over.
The fakes are indistinguishable from the real thing, even by experts. (No surprise, they're made by experts.) Maybe Syria has a harder time, now, disposing of them, with its smuggling routes through Iraq interfered with. (Closed? You must be kidding.) Who knows how much is being printed in Russia? Dollars are very popular there.
It didn't take long at all to start copying the new bills, which is why the U.S. is going to another design already. You probably have some Syrian bills in your pocket right now. Take a look and see if you can spot them.
Meanwhile the Treasury is harrassing an artist, J.S.Boggs, for drawing funny money by hand and exchanging it for face value. Your tax "dollars" at work.
I guess there's probably no option to turn off Java support.
A swamp cooler will only work if it's hot but not very humid. Here in Boston, for example, it would only make things worse. Note that you can't leave loose papers lying around with a swamp cooler running -- it's like a hurricane in the house.
A ceiling fan makes your air conditioner work much better.
One thing to look for in an air conditioner is the ability to suck in a bit of its air from outside, instead of just recirculating inside air or (with the lever pulled) blowing some inside air out. (Why you would want to do the latter mystifies me, but that's what they do.) Sucking in some outside air helps push some of the cold air into other rooms.
Some ACs can be configured as heat pumps, too, so that when it turns cold they can heat the room, for much less than the cost of running an electric radiant heater, and maybe for less than gas heat, these days. As heat pumps, they cool off the outside air and blow inside air past their hot condenser coils.
Live on the ground floor in summer, the top floor in winter.
Not only that, he never said "it's" when he meant "its".
My favorite element, by the way, is Osmium. It sublimates dreadfully toxic fumes from a solid state at room temperature, and nobody knows exactly what its specific gravity is, nor whether it or Iridium is the heaviest element.
The latter presents a very readable summary of what is perhaps the first rigorous application of the scientific method to history. Since it's the first, he started by answering the big questions of the past thirteen thousand years. Essentially: how did Eurasians come to own the world? He knows, and now I do.
The former is a tour de force covering all aspects of northern experience, from early exploration to detailed descriptions of the critters who survive there, and how. I just open it anywhere, now, and start reading, and am always captivated. The maps alone bring delight.
The better JIT runtimes run bytecodes for most of the code, and compile only the more heavily-used functions to machine code. They collect statistics on which functions and loops are (re-)entered most often, and compile them. The clever ones don't optimize the first time, but only optimize the ones that still take the most time. As a result, the JIT compiler, the bytecode interpreter, and its instrumentation continue to compete for L2 and/or L3 cache long into the runtime of a program.
JIT compilers are heavily constrained in the degree of optimization they can afford to apply because they are running when the program itself is supposed to be running. Also, since they are not operating on source code, much of the context is lost by the time they get a chance to operate. Bytecodes are not very expressive of programmer intent.
Or certain Lisp implementations, likewise. There are several answers to this.
First, when performance matters, O'Caml and Lisp are typically compiled not to bytecodes, but to native code. They can often be optimized rather better than C or C++ because they do not cater to pointer abuses, and because their compilers are written in a language better suited to writing optimizers than C is. Thus, there's no analog to the typical JVM problems of data and code pages unshareable among processes, and no cache pressure from a JIT compiler or its instrumentation and redundant code representations, and some overhead may be played off against better optimization.
Second, I gather that O'Caml makes it easier to avoid abusing GCed memory, so you can often ensure that inner loops don't generate garbage and end up with allocations walking the address space. (Disclaimer: I haven't used O'Caml industrially.)
Third, it is very easy, when writing O'Caml or Lisp, to run afoul of the same GC problems. Thus, serious programs written in O'Caml, such as Unison, must have had special attention paid to avoiding GC-induced problems. The QPX airline fare search system, written in Common Lisp and used on Orbitz and Continental Airlines sites -- perhaps the most heavily used industrial Lisp application in existence -- never GCs. It calls out to a huge C++ library for anything that needs dynamic allocation or floating-point operations.
It's possible to make Java programs go fast, it's just very hard. Compile them to native code with GCJ, turn off runtime checks, and keep the garbage collector and anything that generates garbage under a gimlet eye, and you may get performance comparable to C++. I happen to find it more satisfying to write in C++. Maybe I care more about performance than most, and prefer to work on programs where it matters more. When performance and type-safety don't matter much, I use Python.
One of the reasons is that interactions with caches are hard to model, making it hard to know what to do to minimize problems. Caching is, inherently, a deal with the devil: you get speed but lose understanding. Sometimes you lose the speed too. Even when you understand, there's not much you can do. Sometimes complicated stuff is inherently expensive.
When I say caching, I mean not just CPU caches of RAM, but also RAM caches of (potentially swapped-out) process space. If you allow a naive garbage-collector to operate freely, it will happily consume the entire address space available, typically the sum of available RAM and swap space, before garbage-collecting, so the process will run not from RAM but from swap. When it garbage-collects, too, it has to walk a lot of that memory, and swap it all in.
Just running "ulimit -d" in the shell where the java (or other GC-language) program runs can help a lot. It will GC a lot more often, but if nothing is swapped out, the GC happens a lot faster, and the program's regular execution doesn't have to touch swapped-out pages. You have to know a lot about the program and the data it uses to guess the right ulimit value, and if you guess wrong the program fails, but a thousand-fold speed improvement earns a lot of forgiveness.
Did you really believe garbage collection would mean you don't have to know about memory management? It makes memory management harder, because the problem remains but there's less you can do about it. (For trivial programs it doesn't matter. If you only write trivial programs, though, you might as well find some other job.)
There's a similar effect with the CPU cache and RAM. Ideally you want the program code and the data it operates on all to live in cache, because touching the RAM takes 100 times as long at touching cache. With bytecodes, you have a lot more "cache pressure" -- you have the bytecodes themselves, the just-in-time compiler, and the native code it generates. At the same time, since your memory manager generally can't re-use memory that you just freed, it allocates other memory that, when touched, pushes out something else that was useful (such as program code).
The result is that no matter how clever the JVM is, there's not much it can do to get the performance of real programs close to optimal, or even within a pleasing fraction of equivalent C++ code. This despite all the toy benchmarks that seem to prove otherwise, and which carefully avoid all these real-world problems.
Of all the promised features of Java (like Lisp before it and C# after it), we're left with the sole remaining feature, that its virtual machine specifies precisely (or abstracts away) enough details of the runtime environment that the code is more portable than a faster native implementation, and the code might get written faster for the author having avoided thinking about details that affect performance.
The sole saving grace is that most programs don't have much need to run very fast anyway, or if they do it's hard to prove that they ought to run faster. Most people take what they get without complaining, or without complaining to anybody who cares, or without doing anything to make whoever is responsible uncomfortable enough to have to do anything differently. A whole generation trained to accept programs that crash daily or hourly is thrilled to find a program whose biggest problem is that they suspect it might be sluggish.
Free operating systems run on all the others; obviously that's the real reason GameCube is in decline. The solution is clear: Nintendo needs to release a Linux port! (A NetBSD port will appear, as if by magic, a few weeks after.)
It will be fun to run it under the gCubix GB emulator that runs on Linux.
(Imagine, an Anonymous Coward demonstrating bone-crushing ignorance. What next, flying mallards? Swimming trout?)
A multithreaded program may simply open several connections to the X server, and operate independent UIs. One thread might operate a display window, while another operates a dialog box or progress bar. As far as X is concerned, it's talking to different programs.
Don't go looking for complicated solutions when simple ones are right at hand.