I won't be going on to use 6. It's a nice idea, but it's completely unnecessary. It won't make large projects any easier to manage (the language is still, at heart, an almighty hack -- an impressive one, but still a hack). It won't make OO any cleaner. It won't make development any faster. I'd prefer to use a language [Ruby] which has always been pure synthesis of science and engineering, not some half-baked imposter.
While I agree that Perl 6 may prove more damaging
to the community than helpful (because, if it never
achieves critical mass, it'll turn out to be just
a big embarrassment), I don't agree that Ruby is
a "pure synthesis of science and engineering".
Ruby seems to be a good language, but honestly I've
never gotten motivated to take the time to learn it.
The main reason -- and this is going to sound
trivial and petty -- is the syntax. Whoever
invented Ruby seems to think it was big
innovation to dump C-style braces ({ and
}) and replace them with keywords like
end, and they've gotten rid of the
semicolons at the end of statements in favor of
making distinctions between different kinds of
whitespace (newline versus space or tab).
Why do I care about that? It's not as if I can't
adjust. The problem is, this change seems utterly,
totally gratuitous. It's not an innovation.
Decades ago, the REXX scripting language was doing
things just almost exactly the same way Ruby
appears to do it. The fact is, this trivial lexical
distinction -- which is cosmetic only and
offers no practical
advantage at all either way -- has been hashed out for
decades and
every combination has already been tried.
Since Ruby makes such a point of being different,
it makes me feel like the authors are out of
touch with reality in some way. Either they're
ignorant of computer language history and don't
know that their "innovation" is not innovative
(which means they're not qualified to be inventing
languages),
or they do
know the history, they're
bitter that C has won, and they're
still trying to fight the C vs.
ALGOL syntax war (which means they have a side
agenda other than making the language the best
it can be).
Neither possibility inspires me very much, so
I haven't taken the time to dig deeper and see
if Ruby really is worth learning.
On a mirrored RAID, having them out of sync can be better, at least in theory, if probably not in practice. There's no easy way for software to know where an SATA drive is in its rotation, but if you request the same block at the same time from both drives, one of them will respond first, and it will be sooner on average than if both drives were in sync.
It's possible to make hard drives with
synchronized spindles where the spindles
are in sync but not in phase. You could
put two hard drives precisely 180 degrees
out of phase on a two-disk mirror (or
120 degrees out of phase on a three-disk
mirror, and yes people really do have
three-disk mirrors sometimes), and you'd
get better performance than having the
drives' relative position be random.
Having synchronized spindles seems a lot of work for a max saving of 1/2 revolution... in a 7200rpm drive, 1 revolution is 8.3ms, so 1/2 revolution is 4.15 ms... trying to synchronize spindles to save a maximum of 4.15ms seems to be a lot of effort put in the wrong place. You're better off going to higher rpms to squeeze out those few extra milliseconds...
First of all, it seems to me that synchronizing
motors is fairly easy. The motors are
presumably all locked to a clock anyway, so
all you've got to do is run a cable so that
one drive can slave its clock to a master
clock, plus add in the ability to make
adjustments until they're in the phase you
want, and presto, you have synchronized
spindles.
Second, why does making synchronized
spindles have to be mutually exclusive
with increasing the rotational speed?
Sure, you can increase to 10,000 RPM
or even 15,000 RPM, but drives don't
tend to go much faster than 15,000 RPM,
and if you want a boost beyond that,
synchronized spindles can give it
to you.
And third, the maximum saving is one
revolution. There will be cases when
you seek to the right track, and the
data you want is right there with no
waiting on one disk, but one of the
other disks has just passed the desired
point a tiny bit too early and you've
got to wait for it to make basically
an entire revolution before it comes
around again. Yes, this case is
uncommon, but it is possible. So,
the maximum you can save is one revolution,
although the average is lower. (Close
to the 1/2 you mentioned, although it
depends on usage patterns.)
As a math teacher, it may not be as obvious to you, but as someone who learned trigonometry in school and isn't a math teacher now I can say for certain. When people say they'll never use that in the real world, they're absolutely right.
I admit you don't use it often, but there are
some cases. For instance, recently I was in
a conversation about prices for having your
house re-roofed, and someone asked if a price
quote they'd been given was reasonable.
Someone else asked if they knew the area of
their roof, and the first person didn't
know that and only knew the square footage
of their house.
With trigonometry, if you know the square
footage of the house and you know or can guess
the pitch (angle) of the roof, you can make a
good estimate of the square footage of the roof.
You simply divide the horizontal area the
roof covers by the cosine of the angle of
the roof from the horizontal.
Being able to figure this out on the spot
could save you money (and new roofs are
expensive!) if it helps you take better
advantage of an opportunity have a more
meaningful conversation with someone who
knows about the pricing of roofs.
I would think if these drives are
really designed for RAID (like
other drives have been in the past),
then they would have support for
synchronized spindles.
The idea behind synchronized spindles is
that in order to read data from a disk,
you have to wait for the platter to
come around part of a revolution for
your data to become available, just like
picking up your suitcase on the luggage
carousel at the airport. How long you
need to wait
is a matter of luck, because the disk
can be assumed to be in a random position
when you decide you want your data.
When you have RAID without synchronized
spindles and you want data
that's bigger than the stripe width
(or when you're writing and need to update
the parity),
you have to wait for multiple disks, and
they will tend to be spread out so that
you tend to wait longer than if you were
just waiting for one. With synchronized
spindles, as soon as the whole group hits
the right position, you've got what you're
looking for, and you're done.
So, the point is, not having synchronized
spindles tends to increase average access
time, so having synchronized
spindles is a desirable feature for a
drive designed specifically for RAID.
We need a DAQ that is 16-bit or better, with a sampling rate no less than 100 kHz. Oh, and it has to have two input channels.
Hmm, well, these days there are boards that
do that that are a dime a dozen. Namely,
pro audio cards. The newest generation of
cards does 192 kHz sampling rate at 24-bit
resolution, and I've never seen a card that
has fewer than two input channels.
For example, just pulling
something off the top of my head, the
M-AUDIO Audiophile 192. The list price for this
card is $200. Street price might be closer
to $180. There are tons of other similar
cards available, and some of them even have
Linux drivers if that's a direction you
are interested in going (and if you want
to do the research).
The nice thing about these cards is that
since they're pro, they even have differential
inputs for common mode noise rejection,
if you need that.
Of course, the big down side is that whatever
you have that's driving these inputs has
to be able to drive something that looks
like an audio input. I have no idea what
kind of circuit you've got going in your
lab, what kind of voltage range it has,
what kind of impedence it expects, and
all that.
Also, of course, these cards don't have a
software framework that comes with them
that's set up for experimentation. You're
going to have to open the device and read
the audio data out of it. That might be
fine if all you care about is data
collection and you aren't doing anything
else on the computer (like analyzing
the data and using it to control things)
at the same time. But if your needs are
more complex, then that's probably not the
road you want to go down.
Seems to me like disk space is getting to be more and more of a hassle these days
I'm not sure what you're referring to.
In the time since I got my first hard disk,
the price per megabyte has gone down about
four orders of magnitude, so it seems to
be just getting easier and easier. That
doesn't mean it's easy, though.
nip this in the bud since you have an unlimited budget by getting one of those 1.5TB network-attached storage modules they sell (I've seen them for digital photographers). They have internal RAID and support 1Gb Ethernet, which means you'll need a 1Gb switch and card in all the boxes on your home LAN. (Get fiber if you can, but now we're talking real money, I think.)
What would fiber gain you in this situation?
Are you suggesting it for a purpose? For
my money, gigabit ethernet is fast enough
to overwhelm a PCI bus anyway, so unless
you are using a new machine with a faster
expansion bus, or some motherboard
chipset that has
support for another type of network built in
(but they mostly have gigabit ethernet
support if anything built in), you're not
going to be able to do better than gigabit
throughput anyway.
Since I haven't played with NAS I'm not sure what you can do with them, but I have no reason to think you couldn't set up the RAIDing internally whatever way you wanted--I would personally go with RAID-6, some kind of LVM configuration on top of that, and the latest ReiserFS for my source control partition (lots of small text files).
So you're going to put Linux RAID on top of
a network filesystem mounted from a volume
that's already RAID? And then you're going
to put LVM on top of THAT? Why?!
Since it's all coming from the same NAS
box, you're not going to gain any kind of
reliability. In fact, you will just slow
things down and make them less reliable
because of all the extra levels of software
and configuration that has to be right
if you want to be able to access your data.
You'd be much better off just using a
local disk.
We've looked at N.I. products, we just can't currently afford them from what I've seen.
Hmm, well, would something like
this
fit your needs and your budget? I think
these things are meant for robotics, and
the sampling rate on the A/D is going to be
a really low sampling rate (I think 65 Hz)
and low resolution (around 10 bits), but
that might be good enough for some purposes.
Bloody hell - no wonder your webmail experience is lightning slow. Your using a machine with a clock speed that's half as quick as a ZX81!
Well, you see, it runs at 1.2 MHz when it's
in new Super Ultra Wacko Greenpeace-Member
Environmentalist
Power Saving Mode. The computer is three
orders of magnitude slower, but that's OK,
because the hole in the ozone layer is
growing that much more slowly as a result.
OK, no actually I just typed "MHz" when
I meant "GHz". Oops.
can produce what he calls the "bio-diesel" fuel at about 23 euro cents (30 cents) a liter, which is about one-fifth the price at petrol stations now.
Which is fine, but that's a meaningless
comparison. In the United States,
the tax on gasoline is a huge percentage,
and I've heard that in some places
in Europe, up to
80% of the money you're paying at the
pump goes to taxes, and as little as 20%
of it goes to the actual cost of fuel.
If this is true, that obliterates his factor
of 5 right there.
Can anyone in Germany comment on what
percentage of the money that
you pay at the
pump goes to taxes?
One site I found indicates the tax on diesel
was 47.04 euro cents per liter in 2003 and
65.45 euro cents per liter on gasoline, but
the chart on that site is hard to read
and unclear.
But let's just assume that figure is
accurate and compare things taking into
account taxes. The article says it
costs him 23 euro cents to produce a
liter, and that regular diesel costs
5 times that much at the
pump. That means you pay about 115 euro
cents at the pump.
If his biodiesel were subject to the
same taxes, and if it were free to store
it and transport it and there were no markup
at all anywhere
from manufacturing all the way
to retail sales,
then his biodiesel would be 70 cents per
liter. So, what you pay at the pump right
now is only 1.6 times as much as the minimum
his fuel could ever
really cost if it were
sold at the pump, not 5 times as much.
I use my Yahoo! Mail that I've had since
about 1998 on a daily basis, and I really
only want one new feature:
I want to be able to move to the next message
in the list in well under a second.
Preferably,
now that I am sitting at a computer with a
1.25 MHz PowerPC processor and 1 GB of RAM,
I'd like to be able to do this as fast as I
used to be able to do on a SPARCstation 2
(which had a 40 MHz processor) equipped with
a whopping 64 MB of RAM. Ten years
ago, on that computer that was 1.5 orders of
magnitude slower than the one I'm using now,
I could go to the next message in about
0.1 seconds.
Yes, I realize there are web servers and
things (like the open Internet) involved
here, but it should still be do-able.
If need be, they could easily prefetch
and cache messages in the browser's
memory, so that when I hit the "next"
button, it goes there right away.
And I don't mind if unusually large
messages don't load that quickly.
It would also be nice to be able to jump
from mailbox index to message body and back
in a fraction of a second and vice versa,
while I'm asking for things.
English is extremely, enormously comple.
Take, for example, these two sentences:
Time flies like an arrow.
Fruit flies like a banana.
On the lowest level of structure, they
seem highly similar, but the human mind
sees the structure behind them and
understands the difference. It
knows that "flies" is a noun in one and
a verb in the other.
This kind of knowledge becomes important
for grammar checking. Suppose you added
the word "These" at the beginning of both
sentences. Is that grammatically legal?
As a human, you can rule that out for
the first sentence because
you know that "time" is not the type of
noun that can be modified by a word
like "these". So, a grammar checker has
to know that. That's a royal pain, but
a grammar checker could probably be
coded to handle that. (That is,
if you first figure
out what attribute you really mean when
you say "a noun like 'time'" -- what
property is it of that noun that
you are focusing on? What's that called?
How do you code it?)
Suppose, instead, that you add the word
"always" before the word "like". In the
second sentence, that is legal. In the
first sentence, whether it's legal depends
on whether there is a type of "fly" called
a "time fly" that is capable of being fond
of an arrow. If there is no such thing
as a "time fly", then that makes "flies"
a verb, and putting "always" after the
verb isn't legal, because that's not where
adverbs go in English. But if there is a
such a thing as a "time fly", then the
meaning of the sentence is ambiguous and
it could be grammatically legal or not
depending on the context.
The point is, a truly good grammar checker
requires you to understand the text being
written. That goal is not achievable until
we have achieved Strong AI (true, generalized
machine intelligence). Even approaching that
level of quality still requires a huge
amount
of effort. That's one reason that I don't
see it happening as open source. There's
not much use for a grammar checker that
catches 1/10th of your errors, so it's
sort of an all or nothing game, and all
requires lots of resources.
Yes it does now. The nano click wheel at least comes with a click on the internal soundchip or in the headphones after the you scrolled down one entry up or down in the list.
That's not tactile feedback. That's auditory
feedback. Tactile feedback means that you are
getting feedback through your sense of touch,
not your sense of hearing.
Didn't Quark run a bunch of ads that maligned Adobe's product and basically made Quark come off like a bunch of insecure jerks?
Didn't Dell, in the early days (like the
late 1980's), run
advertisements bragging how their machines
were IBM compatible but bragging that they
were better and faster than IBM machines?
OK, this is going to be a bit of a rant.
The basic problem is, I don't get why people
love the click wheel. Yeah, it looks cool
and minimalist, but people are always raving
about the iPod's user interface, and the
click wheel just doesn't seem to be all
that good in that department.
Let me explain. I own an iPod Mini, and I
like it. It looks cool, the battery life
is quite good, and overall the user
interface is well-designed. But, I primarily
use this thing while I'm on the go (surprise).
As such, I am usually doing something else
while listening to music -- something that
requires 95% of my attention. Namely, driving.
I love that the iPod lets me have a
bunch of songs in the car; previously
I was keeping 10 or 15 CDs in the glove box,
and I was always too lazy to change them out,
so I wound up listening
to the same music over and over and over.
Enter the iPod. Now everything is great. I
got a $5 cable from Radio Shack and wired the
thing into my car stereo's aux input. I keep
the thing in a pocket that's very convenient
to reach even while I'm driving; in fact, I
barely have to move my hand.
So what's the problem? The problem is that
the click wheel has no tactile feedback
at all. It's just a big round thing,
and pressing on it in different places does
different things, but there is no way for
your finger to tell where one place ends
and the other begins. Would you want a
keyboard that is perfectly flat and smooth
across the top so that your fingers can't
tell where one key stops and another starts?
That's what the click wheel is like.
The reason this bugs me is that
99.9% of the time,
I put the thing on shuffle, and I often
want to skip a particular song when it
comes up (if I'm not in the mood for it).
So I reach for the iPod and press the track
skip button, or at least I try. Because
this requires me to push the right quarter
of the wheel, I often get it wrong and
punch the play/pause button or the menu
button instead. Pushing play/pause results
in silence. This is particularly irritating
because many of the songs on the iPod start
with a fade-in or a quiet part, and it's
hard when I'm in the car and there's ambient
noise to tell if the iPod has stopped playing
because I've hit the wrong button
or if the song is just quiet. So I pretty
much have to grab the iPod and pull it up
into my field of view or wait 30 seconds.
Or crank up the volume nearly all the way
to hear the difference and hope I don't
damage my hearing. (Well, my car stereo
isn't that powerful, but you get the idea.)
So, overall, I think the iPod does have a
fairly good
user interface, but I'd really much
rather have the wheel and the buttons
separate. The click wheel as it is
makes the thing unnecessarily hard to
use, and the only payoff you get in return
is the "gee whiz" factor.
In terms of a contribution to computer science, V3
[ of reiserfs ] was able to show that you could store small files in the filesystem as files.
Is that really anything new? SGI's XFS
filesystem, which came out on IRIX 5.3 in
late 1994, had special features for
storing small files' contents inside the
i-node instead of in data blocks. Here's
some text from an XFS
whitepaper on the subject:
Very small files
Most symbolic links and directory files are small files. XFS allows these files to be stored in inodes for increased performance. XFS also uses delayed writes to wait to gather the entire small file in the buffer cache before writing to disk. This reduces the number of writes to disk and extents used for a file.
I am not that familiar with the reiserfs
history, but did reiserfs come out before
1994? My guess is that it didn't.
If not, then perhaps it uses a
different approach
to storing small files or takes it to
a new level, but it doesn't
appear to be the first filesystem ever
to put special emphasis on storing small
files efficiently.
I'm not saying that reiserfs sucks or
anything, but it does seem like an
evolutionary improvement more than a
revolutionary one.
We boot into 3.11 because the operational code was developed using Borland C++, but need to exit 3.11 into DOS for the "RT" interrupt capability of the driver for a A/D data acquisition board. You can imagine the hassles that this has given us. It has become a problem just to upload data to our servers.
Our main problem in upgrading the system is that the board hasn't been supported for years, a driver for anything past DOS was never developed, which was proprietary. AFAIK, the company doesn't even exist, and so its unlikey that we could even find someone who might have the code for us to inspect.
Is there a real reason you have to
stay with this data acquisition board
you're using already? Is it even a PCI
card, or is it ISA (wouldn't be surprising
at all in a Pentium 90 machine)? Can it even plug into a modern
computer? What if the old board you have
now breaks -- can it even be replaced?
If you're going to make a
major change, you might as well get
fully up to date in the process.
To that end, have you thought about just
calling up
National
Instruments and seeing what they have
to offer? They specialize in exactly
this type of product. They have a wide
variety of data acquisition hardware
and software, and they support a wide
variety of operating systems and programming
languages. It's possible
they may even make a turnkey
solution that already does what you need
to do or can be programmed to do it easily.
Of course, it has little or no relevance to media and video processing, as those are related to throughput and bandwidth, not latency.
Probably mostly true, but not entirely.
Consider the case when you're using a computer
in a recording studio to record a bunch of
musicians. In the old days, they used
multitrack tape machines which could be
configured so that each track could be
individually set to record or to play back.
Might then record a drum kit on 5 out of
16 tracks, and then come back and have
someone else (the bass player, then
instrumentalists, then singers) come
and lay down tracks on top of that.
These days, tape is effectively dead, and
people do this all with computers. And
not, generally, with specialized kickass
embedded computers, but with Windows
machines or Macs.
So, what is the relevance of all this to
latency? Well, when you are doing multitrack
recording on a computer, you are doing
something fairly unique: you are recording
a track, but at the same time you are playing
back the tracks that have already been
recorded and the signal you are
getting from the instrument or vocalist
that you're recording right now. So, the
(let's say) guitar player you're recording
hears the drum and bass tracks that have
been recorded as well as his own
guitar,
and all of this is coming through the
computer.
Now, one little quirk about musicians (and
I'm sure you'll understand once you think
about it) is that they really hate hearing
themselves in their headphones if what
they're hearing is coming in 100 ms later
than when they're making the sound. This
tends to throw them off, because rhythm is
an important part of music.
As a result, guys with workstations that
are used for recording are to an extent
after the lowest latency they can get
their hands on. The only way to achieve
this is with a minimum amount of buffering
of the audio data and an OS that can
handle servicing interrupts for the
device driver quickly AND scheduling
the audio software to run in time.
Well, either that or a minimum amount of
buffering and ridiculously over-specced
computer so that the CPU is just so fast
that it doesn't matter as much if the
operating system sucks.
So, a system like this could be really
great for a recording studio. That is,
if Linux had pro-quality recording software
and supported device drivers from
pro-grade A/D and D/A converter manufacturers.
(I'm
not talking about your average Soundblaster
Live here -- I'm talking about things
that can around 16 channels of 24-bit,
192 kHz, both in and out,
simultaneously. Hardware like that is
fairly uncommon, and professional
recording guys are not going to use a
third-party driver -- they want something
with support from the manufacturer of
the hardware, because if the system dies
in the middle of a session, they may have
lost the chance to capture a performance
that can never be reproduced.
My point (other than that Linux has a long
way to go on the application software side
of things for pro audio recording) is that
latency can be a hugely important thing
for audio -- if it's audio that involves
live musicians or an audience in any way.
Does it have a multithreaded interface yet? This is by far my biggest gripe with Firefox.
I agree 100%. There are often pages that I
visit which take a while to load. I load
them in the background in tabs, but the whole
browser grinds nearly to a halt while they
load. In fact, if a flash animation takes
up lots of CPU in one tab, then all the
other tabs, and every other part of the
user interface sometimes locks up for a
minute at a time. This is just sad.
My second big gripe is just general bugginess.
Yes, it takes time to iron out bugs, but
Firefox has had some time. Right now, we're
on 1.0.6, and honestly I'd rather see them
just spend 100% of their effort on a 1.0.7
that is as close to bug free as humanly possible
rather than adding more features. I'm sure
the features they're adding right now are
worthwile overall, but I'd much rather stay
with the feature set I have now and see all
the bugs disappear. The worst one is something
that seems to relate to perhaps an event
queue. Every now and then, something
will happen that seems to cause Firefox to
just stop processing events. I can press
buttons and hit Command-W (I'm on a Mac),
and nothing will happen. But if I hold
down the mouse button inside a window,
somehow this rejuvenates the event queue
and these events get processed eventually.
Totally, totally weird.
The worst part is that it seems that flash
animations use the same thread as the
user interface. So if you have a flash
animation that takes a LOT of CPU, which
lots of them do, then the user interface
becomes unresponsive. This is just silly.
You're taking untrusted code (flash
from whatever web site) and letting
it take CPU time away from critical stuff
like being able to close the window that
contains the CPU-hogging flash code!
1) So you don't have 50,000 domains sitting in one directory. Can get a little slow.
That's an OS-specific problem. For instance,
on Solaris 8 and later, the DNLC (directory
name lookup cache) has been enhanced so
that it can deal with directories with
thousands of entries efficiently.
So, 50,000 might be slow on one operating
system but perfectly fine on another.
2) So if you need to have more than one NFS server, which you will if you have a large customer base, you can separate the base level into different NFS servers.
That's a better reason. This problem could
be solved with automount maps, but that
might be more pain than just doing two-level
hashing.
If someone has an early image, you can do a comparison with the current image. Keep the
pixels that have changed and black (or white)
out the ones that haven't.
That's possible. Maybe it's part of the
challenge.
Note, also, that even if you don't have an
early image, there are still some techniques
you can use to gain information. Especially
if they change the random pixels periodically.
And there are probably some ways to take
advantage of the fact that they've encoded
it as JPEG.
If you want an open-source Java compiler
and an open-source Java virtual machine,
there is nothing stopping you from
writing one. The Java Language Specification
is available for free from Sun's web site,
and so is the
Java Virtual Machine Specification. These
should give you enough information
to make a GPLed implementation if you wish
to do so.
Sun's JVM and compiler are not the only
implementations of Java out there. This
is because Java is a standard.
This gives you the ultimate freedom, because
if you don't like the license of one of the
implementations, you can in theory create
your own implementation that has whatever
license you like. I really don't
get why people think Sun needs to open
source their Java software. Nobody
bitched and moaned when AT&T didn't provide
a GPL C or C++ compiler implementation.
Instead, people created their own
implementation. You may have heard of
it; it's called gcc. How is the
Java situation any different at all?
Well maybe the French weren't that stupid after all: they did manage to relocate while unloading Louisiana onto the US...
Only because they had already reached a point
where it was clear French control of
anything in the New World was pretty
laughable, and they had to pull out anyway.
So Napolean offered the land to the US at a
price that was far, far lower than the US
expected or was willing to pay. It was so
low that even though the negotiators didn't
have the authority to make the purchase, they
went ahead anyway because it was too ridiculously
cheap to pass up. This gave Napolean some
extra cash which allowed him to finance
some wars which ultimately failed.
By the way, the reason the US made the
Louisiana Purchase is the same reason that
they won't
decide not to rebuild New Orleans: having
control of the port at the mouth of the
Mississippi River is extremely valuable.
Ok, not always practical. But honestly, whenever I can I fly Horizon Air because they have a little cart outside the airplane when you board that you put your bags on, and the same cart is outside the airplane when you get off (biggest delay I've ever seen was about 10 minutes).
OK, this sounds like a good system if you are
flying nonstop. But I wouldn't want to try to
deal with this when making a transfer from one
plane to another when I only have 45 minutes
to make my connection. Even if it did only
take 10 minutes to get my bag, that's still
10 minutes out of 45, which gets even more
stressful
if you just got off a plane that was running
late.
The point being, as long as people are meeting
connecting flights, it seems like there will
always be a need for an efficient way to get
bags from one plane to another, and it's
probably more efficient if you don't force
each individual passenger to line up and
collect them.:-)
It wouldn't hurt for computer science students to learn about mainframes, or even limited resource embedded systems. It would make them better, more well-rounded IT folk.
Having spent the last 3 years programming on
Palm OS, let me just say that working in
a limited resource embedded system will
hurt. But, you do get something out
of it: most of the programs I've done in
the last few years run fine on systems with
256kB of dynamic heap and 4kB of stack.
Slashdot Mirror
While I agree that Perl 6 may prove more damaging to the community than helpful (because, if it never achieves critical mass, it'll turn out to be just a big embarrassment), I don't agree that Ruby is a "pure synthesis of science and engineering".
Ruby seems to be a good language, but honestly I've never gotten motivated to take the time to learn it. The main reason -- and this is going to sound trivial and petty -- is the syntax. Whoever invented Ruby seems to think it was big innovation to dump C-style braces ({ and }) and replace them with keywords like end, and they've gotten rid of the semicolons at the end of statements in favor of making distinctions between different kinds of whitespace (newline versus space or tab).
Why do I care about that? It's not as if I can't adjust. The problem is, this change seems utterly, totally gratuitous. It's not an innovation. Decades ago, the REXX scripting language was doing things just almost exactly the same way Ruby appears to do it. The fact is, this trivial lexical distinction -- which is cosmetic only and offers no practical advantage at all either way -- has been hashed out for decades and every combination has already been tried. Since Ruby makes such a point of being different, it makes me feel like the authors are out of touch with reality in some way. Either they're ignorant of computer language history and don't know that their "innovation" is not innovative (which means they're not qualified to be inventing languages), or they do know the history, they're bitter that C has won, and they're still trying to fight the C vs. ALGOL syntax war (which means they have a side agenda other than making the language the best it can be). Neither possibility inspires me very much, so I haven't taken the time to dig deeper and see if Ruby really is worth learning.
It's possible to make hard drives with synchronized spindles where the spindles are in sync but not in phase. You could put two hard drives precisely 180 degrees out of phase on a two-disk mirror (or 120 degrees out of phase on a three-disk mirror, and yes people really do have three-disk mirrors sometimes), and you'd get better performance than having the drives' relative position be random.
First of all, it seems to me that synchronizing motors is fairly easy. The motors are presumably all locked to a clock anyway, so all you've got to do is run a cable so that one drive can slave its clock to a master clock, plus add in the ability to make adjustments until they're in the phase you want, and presto, you have synchronized spindles.
Second, why does making synchronized spindles have to be mutually exclusive with increasing the rotational speed? Sure, you can increase to 10,000 RPM or even 15,000 RPM, but drives don't tend to go much faster than 15,000 RPM, and if you want a boost beyond that, synchronized spindles can give it to you.
And third, the maximum saving is one revolution. There will be cases when you seek to the right track, and the data you want is right there with no waiting on one disk, but one of the other disks has just passed the desired point a tiny bit too early and you've got to wait for it to make basically an entire revolution before it comes around again. Yes, this case is uncommon, but it is possible. So, the maximum you can save is one revolution, although the average is lower. (Close to the 1/2 you mentioned, although it depends on usage patterns.)
I admit you don't use it often, but there are some cases. For instance, recently I was in a conversation about prices for having your house re-roofed, and someone asked if a price quote they'd been given was reasonable. Someone else asked if they knew the area of their roof, and the first person didn't know that and only knew the square footage of their house.
With trigonometry, if you know the square footage of the house and you know or can guess the pitch (angle) of the roof, you can make a good estimate of the square footage of the roof. You simply divide the horizontal area the roof covers by the cosine of the angle of the roof from the horizontal.
Being able to figure this out on the spot could save you money (and new roofs are expensive!) if it helps you take better advantage of an opportunity have a more meaningful conversation with someone who knows about the pricing of roofs.
I would think if these drives are really designed for RAID (like other drives have been in the past), then they would have support for synchronized spindles.
The idea behind synchronized spindles is that in order to read data from a disk, you have to wait for the platter to come around part of a revolution for your data to become available, just like picking up your suitcase on the luggage carousel at the airport. How long you need to wait is a matter of luck, because the disk can be assumed to be in a random position when you decide you want your data. When you have RAID without synchronized spindles and you want data that's bigger than the stripe width (or when you're writing and need to update the parity), you have to wait for multiple disks, and they will tend to be spread out so that you tend to wait longer than if you were just waiting for one. With synchronized spindles, as soon as the whole group hits the right position, you've got what you're looking for, and you're done.
So, the point is, not having synchronized spindles tends to increase average access time, so having synchronized spindles is a desirable feature for a drive designed specifically for RAID.
Hmm, well, these days there are boards that do that that are a dime a dozen. Namely, pro audio cards. The newest generation of cards does 192 kHz sampling rate at 24-bit resolution, and I've never seen a card that has fewer than two input channels. For example, just pulling something off the top of my head, the M-AUDIO Audiophile 192. The list price for this card is $200. Street price might be closer to $180. There are tons of other similar cards available, and some of them even have Linux drivers if that's a direction you are interested in going (and if you want to do the research).
The nice thing about these cards is that since they're pro, they even have differential inputs for common mode noise rejection, if you need that. Of course, the big down side is that whatever you have that's driving these inputs has to be able to drive something that looks like an audio input. I have no idea what kind of circuit you've got going in your lab, what kind of voltage range it has, what kind of impedence it expects, and all that.
Also, of course, these cards don't have a software framework that comes with them that's set up for experimentation. You're going to have to open the device and read the audio data out of it. That might be fine if all you care about is data collection and you aren't doing anything else on the computer (like analyzing the data and using it to control things) at the same time. But if your needs are more complex, then that's probably not the road you want to go down.
I'm not sure what you're referring to. In the time since I got my first hard disk, the price per megabyte has gone down about four orders of magnitude, so it seems to be just getting easier and easier. That doesn't mean it's easy, though.
What would fiber gain you in this situation? Are you suggesting it for a purpose? For my money, gigabit ethernet is fast enough to overwhelm a PCI bus anyway, so unless you are using a new machine with a faster expansion bus, or some motherboard chipset that has support for another type of network built in (but they mostly have gigabit ethernet support if anything built in), you're not going to be able to do better than gigabit throughput anyway.
So you're going to put Linux RAID on top of a network filesystem mounted from a volume that's already RAID? And then you're going to put LVM on top of THAT? Why?! Since it's all coming from the same NAS box, you're not going to gain any kind of reliability. In fact, you will just slow things down and make them less reliable because of all the extra levels of software and configuration that has to be right if you want to be able to access your data. You'd be much better off just using a local disk.
Hmm, well, would something like this fit your needs and your budget? I think these things are meant for robotics, and the sampling rate on the A/D is going to be a really low sampling rate (I think 65 Hz) and low resolution (around 10 bits), but that might be good enough for some purposes.
Well, you see, it runs at 1.2 MHz when it's in new Super Ultra Wacko Greenpeace-Member Environmentalist Power Saving Mode. The computer is three orders of magnitude slower, but that's OK, because the hole in the ozone layer is growing that much more slowly as a result.
OK, no actually I just typed "MHz" when I meant "GHz". Oops.
TFA says he
Which is fine, but that's a meaningless comparison. In the United States, the tax on gasoline is a huge percentage, and I've heard that in some places in Europe, up to 80% of the money you're paying at the pump goes to taxes, and as little as 20% of it goes to the actual cost of fuel. If this is true, that obliterates his factor of 5 right there.
Can anyone in Germany comment on what percentage of the money that you pay at the pump goes to taxes? One site I found indicates the tax on diesel was 47.04 euro cents per liter in 2003 and 65.45 euro cents per liter on gasoline, but the chart on that site is hard to read and unclear.
But let's just assume that figure is accurate and compare things taking into account taxes. The article says it costs him 23 euro cents to produce a liter, and that regular diesel costs 5 times that much at the pump. That means you pay about 115 euro cents at the pump. If his biodiesel were subject to the same taxes, and if it were free to store it and transport it and there were no markup at all anywhere from manufacturing all the way to retail sales, then his biodiesel would be 70 cents per liter. So, what you pay at the pump right now is only 1.6 times as much as the minimum his fuel could ever really cost if it were sold at the pump, not 5 times as much.
I use my Yahoo! Mail that I've had since about 1998 on a daily basis, and I really only want one new feature: I want to be able to move to the next message in the list in well under a second.
Preferably, now that I am sitting at a computer with a 1.25 MHz PowerPC processor and 1 GB of RAM, I'd like to be able to do this as fast as I used to be able to do on a SPARCstation 2 (which had a 40 MHz processor) equipped with a whopping 64 MB of RAM. Ten years ago, on that computer that was 1.5 orders of magnitude slower than the one I'm using now, I could go to the next message in about 0.1 seconds.
Yes, I realize there are web servers and things (like the open Internet) involved here, but it should still be do-able. If need be, they could easily prefetch and cache messages in the browser's memory, so that when I hit the "next" button, it goes there right away. And I don't mind if unusually large messages don't load that quickly.
It would also be nice to be able to jump from mailbox index to message body and back in a fraction of a second and vice versa, while I'm asking for things.
English is extremely, enormously comple. Take, for example, these two sentences:
On the lowest level of structure, they seem highly similar, but the human mind sees the structure behind them and understands the difference. It knows that "flies" is a noun in one and a verb in the other.
This kind of knowledge becomes important for grammar checking. Suppose you added the word "These" at the beginning of both sentences. Is that grammatically legal? As a human, you can rule that out for the first sentence because you know that "time" is not the type of noun that can be modified by a word like "these". So, a grammar checker has to know that. That's a royal pain, but a grammar checker could probably be coded to handle that. (That is, if you first figure out what attribute you really mean when you say "a noun like 'time'" -- what property is it of that noun that you are focusing on? What's that called? How do you code it?)
Suppose, instead, that you add the word "always" before the word "like". In the second sentence, that is legal. In the first sentence, whether it's legal depends on whether there is a type of "fly" called a "time fly" that is capable of being fond of an arrow. If there is no such thing as a "time fly", then that makes "flies" a verb, and putting "always" after the verb isn't legal, because that's not where adverbs go in English. But if there is a such a thing as a "time fly", then the meaning of the sentence is ambiguous and it could be grammatically legal or not depending on the context.
The point is, a truly good grammar checker requires you to understand the text being written. That goal is not achievable until we have achieved Strong AI (true, generalized machine intelligence). Even approaching that level of quality still requires a huge amount of effort. That's one reason that I don't see it happening as open source. There's not much use for a grammar checker that catches 1/10th of your errors, so it's sort of an all or nothing game, and all requires lots of resources.
That's not tactile feedback. That's auditory feedback. Tactile feedback means that you are getting feedback through your sense of touch, not your sense of hearing.
Didn't Dell, in the early days (like the late 1980's), run advertisements bragging how their machines were IBM compatible but bragging that they were better and faster than IBM machines?
OK, this is going to be a bit of a rant. The basic problem is, I don't get why people love the click wheel. Yeah, it looks cool and minimalist, but people are always raving about the iPod's user interface, and the click wheel just doesn't seem to be all that good in that department.
Let me explain. I own an iPod Mini, and I like it. It looks cool, the battery life is quite good, and overall the user interface is well-designed. But, I primarily use this thing while I'm on the go (surprise). As such, I am usually doing something else while listening to music -- something that requires 95% of my attention. Namely, driving. I love that the iPod lets me have a bunch of songs in the car; previously I was keeping 10 or 15 CDs in the glove box, and I was always too lazy to change them out, so I wound up listening to the same music over and over and over.
Enter the iPod. Now everything is great. I got a $5 cable from Radio Shack and wired the thing into my car stereo's aux input. I keep the thing in a pocket that's very convenient to reach even while I'm driving; in fact, I barely have to move my hand.
So what's the problem? The problem is that the click wheel has no tactile feedback at all. It's just a big round thing, and pressing on it in different places does different things, but there is no way for your finger to tell where one place ends and the other begins. Would you want a keyboard that is perfectly flat and smooth across the top so that your fingers can't tell where one key stops and another starts? That's what the click wheel is like.
The reason this bugs me is that 99.9% of the time, I put the thing on shuffle, and I often want to skip a particular song when it comes up (if I'm not in the mood for it). So I reach for the iPod and press the track skip button, or at least I try. Because this requires me to push the right quarter of the wheel, I often get it wrong and punch the play/pause button or the menu button instead. Pushing play/pause results in silence. This is particularly irritating because many of the songs on the iPod start with a fade-in or a quiet part, and it's hard when I'm in the car and there's ambient noise to tell if the iPod has stopped playing because I've hit the wrong button or if the song is just quiet. So I pretty much have to grab the iPod and pull it up into my field of view or wait 30 seconds. Or crank up the volume nearly all the way to hear the difference and hope I don't damage my hearing. (Well, my car stereo isn't that powerful, but you get the idea.)
So, overall, I think the iPod does have a fairly good user interface, but I'd really much rather have the wheel and the buttons separate. The click wheel as it is makes the thing unnecessarily hard to use, and the only payoff you get in return is the "gee whiz" factor.
The interview says this:
Is that really anything new? SGI's XFS filesystem, which came out on IRIX 5.3 in late 1994, had special features for storing small files' contents inside the i-node instead of in data blocks. Here's some text from an XFS whitepaper on the subject:
I am not that familiar with the reiserfs history, but did reiserfs come out before 1994? My guess is that it didn't. If not, then perhaps it uses a different approach to storing small files or takes it to a new level, but it doesn't appear to be the first filesystem ever to put special emphasis on storing small files efficiently.
I'm not saying that reiserfs sucks or anything, but it does seem like an evolutionary improvement more than a revolutionary one.
Is there a real reason you have to stay with this data acquisition board you're using already? Is it even a PCI card, or is it ISA (wouldn't be surprising at all in a Pentium 90 machine)? Can it even plug into a modern computer? What if the old board you have now breaks -- can it even be replaced? If you're going to make a major change, you might as well get fully up to date in the process.
To that end, have you thought about just calling up National Instruments and seeing what they have to offer? They specialize in exactly this type of product. They have a wide variety of data acquisition hardware and software, and they support a wide variety of operating systems and programming languages. It's possible they may even make a turnkey solution that already does what you need to do or can be programmed to do it easily.
Probably mostly true, but not entirely. Consider the case when you're using a computer in a recording studio to record a bunch of musicians. In the old days, they used multitrack tape machines which could be configured so that each track could be individually set to record or to play back. Might then record a drum kit on 5 out of 16 tracks, and then come back and have someone else (the bass player, then instrumentalists, then singers) come and lay down tracks on top of that.
These days, tape is effectively dead, and people do this all with computers. And not, generally, with specialized kickass embedded computers, but with Windows machines or Macs.
So, what is the relevance of all this to latency? Well, when you are doing multitrack recording on a computer, you are doing something fairly unique: you are recording a track, but at the same time you are playing back the tracks that have already been recorded and the signal you are getting from the instrument or vocalist that you're recording right now. So, the (let's say) guitar player you're recording hears the drum and bass tracks that have been recorded as well as his own guitar, and all of this is coming through the computer.
Now, one little quirk about musicians (and I'm sure you'll understand once you think about it) is that they really hate hearing themselves in their headphones if what they're hearing is coming in 100 ms later than when they're making the sound. This tends to throw them off, because rhythm is an important part of music.
As a result, guys with workstations that are used for recording are to an extent after the lowest latency they can get their hands on. The only way to achieve this is with a minimum amount of buffering of the audio data and an OS that can handle servicing interrupts for the device driver quickly AND scheduling the audio software to run in time. Well, either that or a minimum amount of buffering and ridiculously over-specced computer so that the CPU is just so fast that it doesn't matter as much if the operating system sucks.
So, a system like this could be really great for a recording studio. That is, if Linux had pro-quality recording software and supported device drivers from pro-grade A/D and D/A converter manufacturers. (I'm not talking about your average Soundblaster Live here -- I'm talking about things that can around 16 channels of 24-bit, 192 kHz, both in and out, simultaneously. Hardware like that is fairly uncommon, and professional recording guys are not going to use a third-party driver -- they want something with support from the manufacturer of the hardware, because if the system dies in the middle of a session, they may have lost the chance to capture a performance that can never be reproduced.
My point (other than that Linux has a long way to go on the application software side of things for pro audio recording) is that latency can be a hugely important thing for audio -- if it's audio that involves live musicians or an audience in any way.
I agree 100%. There are often pages that I visit which take a while to load. I load them in the background in tabs, but the whole browser grinds nearly to a halt while they load. In fact, if a flash animation takes up lots of CPU in one tab, then all the other tabs, and every other part of the user interface sometimes locks up for a minute at a time. This is just sad.
My second big gripe is just general bugginess. Yes, it takes time to iron out bugs, but Firefox has had some time. Right now, we're on 1.0.6, and honestly I'd rather see them just spend 100% of their effort on a 1.0.7 that is as close to bug free as humanly possible rather than adding more features. I'm sure the features they're adding right now are worthwile overall, but I'd much rather stay with the feature set I have now and see all the bugs disappear. The worst one is something that seems to relate to perhaps an event queue. Every now and then, something will happen that seems to cause Firefox to just stop processing events. I can press buttons and hit Command-W (I'm on a Mac), and nothing will happen. But if I hold down the mouse button inside a window, somehow this rejuvenates the event queue and these events get processed eventually. Totally, totally weird.
The worst part is that it seems that flash animations use the same thread as the user interface. So if you have a flash animation that takes a LOT of CPU, which lots of them do, then the user interface becomes unresponsive. This is just silly. You're taking untrusted code (flash from whatever web site) and letting it take CPU time away from critical stuff like being able to close the window that contains the CPU-hogging flash code!
That's an OS-specific problem. For instance, on Solaris 8 and later, the DNLC (directory name lookup cache) has been enhanced so that it can deal with directories with thousands of entries efficiently. So, 50,000 might be slow on one operating system but perfectly fine on another.
That's a better reason. This problem could be solved with automount maps, but that might be more pain than just doing two-level hashing.
That's possible. Maybe it's part of the challenge.
Note, also, that even if you don't have an early image, there are still some techniques you can use to gain information. Especially if they change the random pixels periodically. And there are probably some ways to take advantage of the fact that they've encoded it as JPEG.
If you want an open-source Java compiler and an open-source Java virtual machine, there is nothing stopping you from writing one. The Java Language Specification is available for free from Sun's web site, and so is the Java Virtual Machine Specification. These should give you enough information to make a GPLed implementation if you wish to do so.
Sun's JVM and compiler are not the only implementations of Java out there. This is because Java is a standard. This gives you the ultimate freedom, because if you don't like the license of one of the implementations, you can in theory create your own implementation that has whatever license you like. I really don't get why people think Sun needs to open source their Java software. Nobody bitched and moaned when AT&T didn't provide a GPL C or C++ compiler implementation. Instead, people created their own implementation. You may have heard of it; it's called gcc. How is the Java situation any different at all?
Only because they had already reached a point where it was clear French control of anything in the New World was pretty laughable, and they had to pull out anyway. So Napolean offered the land to the US at a price that was far, far lower than the US expected or was willing to pay. It was so low that even though the negotiators didn't have the authority to make the purchase, they went ahead anyway because it was too ridiculously cheap to pass up. This gave Napolean some extra cash which allowed him to finance some wars which ultimately failed.
By the way, the reason the US made the Louisiana Purchase is the same reason that they won't decide not to rebuild New Orleans: having control of the port at the mouth of the Mississippi River is extremely valuable.
OK, this sounds like a good system if you are flying nonstop. But I wouldn't want to try to deal with this when making a transfer from one plane to another when I only have 45 minutes to make my connection. Even if it did only take 10 minutes to get my bag, that's still 10 minutes out of 45, which gets even more stressful if you just got off a plane that was running late.
The point being, as long as people are meeting connecting flights, it seems like there will always be a need for an efficient way to get bags from one plane to another, and it's probably more efficient if you don't force each individual passenger to line up and collect them. :-)
Having spent the last 3 years programming on Palm OS, let me just say that working in a limited resource embedded system will hurt. But, you do get something out of it: most of the programs I've done in the last few years run fine on systems with 256kB of dynamic heap and 4kB of stack.