It doesn't look like you're getting a lot of help from the Slashbots on this one, unfortunately...
If anyone with good programming skills is in the mood to help, the best way to help out would be to get reliable write access to HFS+ filesystems, either through the kernel module or the user-mode utilities (the author's page is here)
Anyway, back to Jason, your webpage has listed, for at least a couple monthe now, several people who are "working on" things like write support in hfsplusutils and iTunes database manipulation, but there is no indication of what the status is on those projects. What's happening along those lines?
Unfortunately, it wil have a Pentium 5, which will require a heat sink the size of Utah.
Re:Yeah! But try getting it to look as nice as LaT
on
Penguin2Apple
·
· Score: 1
When I'm done with a document, BTW, that gets published, I don't send it out. It goes to a technical writer that formats it in (sometimes in Quark). This technical writer would have to learn LaTeX instead of a point-and-click program.
Depends on your audience. If you're publishing in a scientific journal, which is my situation, chances are about 95% that LaTeX is the first choice for recieving submissions. Chances are also pretty good that they won't accept any formats other than TeX.
Obviously the content of the paper is beyond (without a serious time investment) about 99.999% of the Slashdot population (definitely including myself)
If the content of the paper is beyond your comprehension, why are you making statements about it? There's nothing in this paper that any reasonably competent electrical engineering undergraduate wouldn't be able to do in 3 days given access to the equipment (a photomultiplier and a 250MHz digital oscilliscope were the only recording equipment used.)
however scanning through it it simply sounds like an absurd premise : A computer monitor is not a flashlight, but is rather an ambient source of light whose net effect on any section of an opposing wall would not, in my opinion, be a "image" but a composite of all of the pixels put together.
The claim is not that an "image" is projected on the wall. The entirely obvious claim is that the image is encoded in the time domain. RTFA.
The timing of the scanlines is a consideration, however given the phosphor decay with the unknown intensity of the drawn pixels (i.e. pixels in the middle of the screen may still be brighter than the pixels being drawn at the top) make the idea of reading from diffuse reflection seemingly absurd for anything other than extremely high contrast test cases.
You haven't been scanning through the paper too well. Dealing with the impulse response fo the phosphors is what sections 3 and 4 are devoted to. The phosphor response is simply a linear convolution filter. Approximate deconvolution is covered in any undergraduate-level signals class.
The Caps-lock key on the keyboard physically sends only one event per keypress. I.E. the toggle action is built in to the keyboard rather than being handled in the protocol or drivers. Furthermore the event gets sent on the downstroke the first time, but on the upstroke when Caps-lock is released -- so there's not even a reasonable way to emulate Control-key behavior. This issue gets rehashed on debian-powerpc-user about every month.
This "flaw" really only makes a difference if you're an Emacs person. I prefer Vim personally. *ducks*
It's because they're tired of Apple user's tireless honest answers to stupid flames:
CmdrTaco: Oh yeah, the new xMac is out. It can burn DVDs and run BSD software while preparing you a tasteful, healthy meal for you every day and never needs to be taken for a walk, and it actually looks halfway decent, but I won't ever use it because it ships with a one-button mouse.
Mac-using hordes: BUY A GODDAMN $10 3-BUTTON MOUSE ALREADY!
Taco: All right, I'm sectioning off a Mac ghetto and sending you there so I don't have to listen anymore.
BTW, I couldn't post to this article without going through apple.slashdot.org. That's annoying. And a shiny ugly green theme is still an ugly green theme.
You can turn the Gnutella network into some kind of "virtual" hypercube or hypertorus all you like, but that doesn't change the physical reality of the system, viz:
The Internet has a structure with physical limitations!
What good does it do if your many multiply redundant connections allow transmission of messages with a fewer number of virtual hops, when every connection going out of your college dorm goes over the same physical wire. The number of connections over which a search request must travel is a liability, not an asset, when many of those connections happen to use the same physical wire. The author of this "paper" has conveniently ignored this fact, and his conclusion (that adding virtual links to your network allows you to manufacture bandwidth out of thin air) follows directly.
On a separate topic, the assertion that the virtual connectivity of Gnutella is anything like a Cayley tree is absurd, because it implies no closed paths. Consider: In order to discover and connect to a new a host on the Gnutella network, you need to catch a search request originating from that host. The fact that you were able to recieve that search request in the first place means that there was already a path between you and the remote host--therefore you have created at least one closed cycle by forming the new connection.
The problem here is that the populace views the internet as a way to buy books, talk to friends, send e-mails, and of course... view porn. This is not what the internet was created for....
The internet was created as a means of communication and sharing of information.
I'm sorry, I fail to see the difference between the first thing (that the internet was "not created for") and the second (that the internet "was created for.") Buying books, talking to friends, sending e-mails, and viewing porn are all means of communication and sharing of information. Just so happens that some of the information is in the form of pornos.
Telephones were invented to allow people to talk to each other over a distance. That includes phone sex. Photography was invented to record images--that includes sexual images. It's liek you're saying I can't use a hammer to drive stakes into the ground because it was only "invented for" driving nails into wood.
Uhm, ATI has refuced to release the specs for several key features of their vodeo chipsets (notably the MPEG-decoding-related features of hardware IDCT and motion compentation.)
Consequently I have to reboot my laptop to a closed OS whenever I want to watch a DVD at more than 10 fps.
Considering the guts of the device are a 1.8-inch hard disk that retails for as much or more than the iPod itself, PLUS an exotic rechargable battery, custom case and interface, and a relatively expensive LCD, I think it might be safe to say that apple is making little to no profit on the iPod at its current price point.
So, really, selling more iPods isn't the point. Selling more Macs is. Thus the Mac-centeredness of the device.
Yeah. Hook a big electromagnet to your house mains and wave it at your hard drive. Not only will it hum audibly when connected to AC current, but when you try to read your data you will find out first hand about electromagnetic noise.
Now imagine a fan with rapidly spinning and switching magnets sitting on top of a next-generation CPU with such a fine process that only two or three electrons constitute the difference between a "1" and a "0". Are you beginning to see the problem?
The problem with incrementals, as you point out, is that you tend to scatter the important data across a bunch of disks and tapes. But a good algorithm can keep the disk set down.
Since a CDR is fixed-size and write-once, there will usually be a sizable chunk of space left over after getting the changes. You can use the extra space to trim the size of your restore set--say, after computing the diff for this week, the software decides that it needs to use 350 MB to back up all of this week's changes. Then it looks at its database and sees that all but 280 MB of data on some previous disc has been obsoleted. Then it simply copies that 280MB over again onto the new disk, and tells you you can throw away the old disk. That way you can limit the maximum size of the restore set. You can also occasionally burn consolidation discs that condense the non-obsoleted data from a bunch of discs onto one. The discs should never be on average more than 50% obsolete if you do it right, and that puts a hard cap on the size of the disc collection you have to keep.
Also, in this particular question, it's a family server being backed up, not a corporate server--cheap is important, convenience and speed of backing up is important (because it's a hard habit to keep on a home computer,) and you can simply pay the kid a couple bucks to sit there and feed CDRs if/when you need to restore (I've been there too.)
Back in the day, you would actually buy software packages dedicated to doing backup. And they all did s thing called "incremental backup." That meant that they kept a database of all the files on your disk, and they would only copy the files which had changed since your last backup.
That worked really well for backing up our 80MB drives onto stacks of 1.44MB floppies, since you would really only need to insert about 5-10 floppies during your weekly backup, just to get the files that changed.
So why not just do incremental backup onto CD-Rs? Even with 100GB of archives, most of those are static. You probably won't need to use more than one CDR per week (maybe two) to track the changes. It's cheap, relatively painless if you've got the right software (and it wouldn't be hard to throw together incremental backup/recovery scripts in Perl if you're into that sort of thing.) and you've probably already got a CD burner.
If less than 650MB of files change in a week, the rest of the CDR can be filled up with files that were on earlier CDRs (this way your backup set can remain finite and you can throw out the earlier CDRs as they become obsolete. Or if you keep them all, you can reconstruct that state of your hard drive at *any* time, not just at the last backup.) This seems ideal to me--why is everyone else talking about expensive solutions like tape drives, DVD-RWs, and second hard drives?
Okay, think of it this way. There are 12 blades evenly spaced. Therefore, rotating the fan 1/12 of a revolution makes it look like it did at the start.
If the fan were going to make 40Khz noise, that would indicate that there is a process which takes on the same configuration only once every revolution. This is not the case here; the system looks the same 12 times every revolution. So the sound produced is at 480 KHz.
Your orchestra example is also bogus. If you were to take the sound of a violin playing one note, and layer on 11 more copies of the same sound, all being out-of-phase with each other by 1/12 cycle (which is what we have with the fan), you would *not* hear the original sound. You would hear the 12th harmonic of the volin, and all multiples thereof. In DSP books, it's called a comb filter.
You nimrod, LCDs have NEVER had a better light-to-darkness ratio than CRTs.
Compare the numbers here
to the numbers here and be aware that on LCDs, contrast ratio comes at a premium price--there's no way you're going to get a $400 LCD with comparable contrast to a $100 CRT.
And you're forgetting about color gamut entirely, which is just as important. LCDs have terrible color range compared to CRTs.
1. Disc skipping on portable CD players is not as critical issue as it used to be. Once shock memory reached over 20 seconds on portable players unless you really jostle the player very hard disk skipping was pretty much alleviated. That meant you could jog with the player running and chances were pretty good you wouldn't hear skipping.
From personal experience, that isn't likely. All the good a 40-second buffer does you is that you can jostle a player for 40 seconds before it starts to skip. When jogging, you are continually jostling the player. That means you can jog for 40 seconds without incurring a skip, but after that, it's over. You can definitely walk around with them, but running is out of the question.
The roads out near my house are packed dirt which is heavily prone to washboarding. While most car and portable CD players have decent skip protection, I haven't seen one that could handle being driven over these roads for more than a minute.
Yeah, I did... for me it was a harmless college stunt (the lines outside Mann's Chinese had a "system" where you could camp out part-time and your position in line was determined by how many hours you had logged. Solution: go to class during the day, sleep on the street at night.)
Still, the result was disappointing at best. I learned a couple of things:
The people who do this sort of thing are WAY far out of touch with reality, and
Fercrissakes, don't get yourself worked up over the impending release of a film that may or may not be good.
A casual "I'll see it when I get around to it, if I hear it's good" attitude makes for a much more enjoyable experience.
But the ultimate lesson is that people have an amazing tendency not to be able to learn from other people's mistakes. Unless they're so far gone that they think they actually gained anything by camping out for Episode 1...
FFT is exactly the wrong technique for resolving transient or plosive sounds. Wavelets work better. Take the CWT of a person speaking, and you can *see* the shape of all the consonants.
When people speak, it is the consonants that matter. Ever try listening closely to someone with a pronounced regional accent? The vowels are all jumbled up but the speech is still intelligible. IIRC, people tried to teach gorillas to communicate using different grunts, and gave up in favor of sign language. Reason being that you *can't* string two different vowels together without a consonant in between and have it be intelligible.
Slashdot Mirror
It doesn't look like you're getting a lot of help from the Slashbots on this one, unfortunately...
If anyone with good programming skills is in the mood to help, the best way to help out would be to get reliable write access to HFS+ filesystems, either through the kernel module or the user-mode utilities (the author's page is here)
Anyway, back to Jason, your webpage has listed, for at least a couple monthe now, several people who are "working on" things like write support in hfsplusutils and iTunes database manipulation, but there is no indication of what the status is on those projects. What's happening along those lines?
Unfortunately, it wil have a Pentium 5, which will require a heat sink the size of Utah.
When I'm done with a document, BTW, that gets published, I don't send it out. It goes to a technical writer that formats it in (sometimes in Quark). This technical writer would have to learn LaTeX instead of a point-and-click program.
Depends on your audience. If you're publishing in a scientific journal, which is my situation, chances are about 95% that LaTeX is the first choice for recieving submissions. Chances are also pretty good that they won't accept any formats other than TeX.
So what's the advantage over Linux in this case?
If the content of the paper is beyond your comprehension, why are you making statements about it? There's nothing in this paper that any reasonably competent electrical engineering undergraduate wouldn't be able to do in 3 days given access to the equipment (a photomultiplier and a 250MHz digital oscilliscope were the only recording equipment used.)
however scanning through it it simply sounds like an absurd premise : A computer monitor is not a flashlight, but is rather an ambient source of light whose net effect on any section of an opposing wall would not, in my opinion, be a "image" but a composite of all of the pixels put together.
The claim is not that an "image" is projected on the wall. The entirely obvious claim is that the image is encoded in the time domain. RTFA.
The timing of the scanlines is a consideration, however given the phosphor decay with the unknown intensity of the drawn pixels (i.e. pixels in the middle of the screen may still be brighter than the pixels being drawn at the top) make the idea of reading from diffuse reflection seemingly absurd for anything other than extremely high contrast test cases.
You haven't been scanning through the paper too well. Dealing with the impulse response fo the phosphors is what sections 3 and 4 are devoted to. The phosphor response is simply a linear convolution filter. Approximate deconvolution is covered in any undergraduate-level signals class.
That's a poor example, since the copyright on War and Peace has expired and passed it into public domain.
The Mac laptops still use ADB for their internal keyboard and touchpad:
luser@puter:~$ dmesg | grep -i adb
--
adb: starting probe task...
adb devices: [2]: 2 c3 [3]: 3 1 [7]: 7 1f
ADB keyboard at 2, handler 1
ADB mouse at 3, handler set to 4 (trackpad)
adb: finished probe task...
This in a recent iBook.
The Caps-lock key on the keyboard physically sends only one event per keypress. I.E. the toggle action is built in to the keyboard rather than being handled in the protocol or drivers. Furthermore the event gets sent on the downstroke the first time, but on the upstroke when Caps-lock is released -- so there's not even a reasonable way to emulate Control-key behavior. This issue gets rehashed on debian-powerpc-user about every month.
This "flaw" really only makes a difference if you're an Emacs person. I prefer Vim personally. *ducks*
You do know that there is already AppleWorks for Windows?
It's because they're tired of Apple user's tireless honest answers to stupid flames:
CmdrTaco: Oh yeah, the new xMac is out. It can burn DVDs and run BSD software while preparing you a tasteful, healthy meal for you every day and never needs to be taken for a walk, and it actually looks halfway decent, but I won't ever use it because it ships with a one-button mouse.
Mac-using hordes: BUY A GODDAMN $10 3-BUTTON MOUSE ALREADY!
Taco: All right, I'm sectioning off a Mac ghetto and sending you there so I don't have to listen anymore.
BTW, I couldn't post to this article without going through apple.slashdot.org. That's annoying. And a shiny ugly green theme is still an ugly green theme.
This was posted to kuro5hin as well, not too long ago.
OK, I'm done link-whoring, go about your business...
The Internet has a structure with physical limitations!
What good does it do if your many multiply redundant connections allow transmission of messages with a fewer number of virtual hops, when every connection going out of your college dorm goes over the same physical wire. The number of connections over which a search request must travel is a liability, not an asset, when many of those connections happen to use the same physical wire. The author of this "paper" has conveniently ignored this fact, and his conclusion (that adding virtual links to your network allows you to manufacture bandwidth out of thin air) follows directly.
On a separate topic, the assertion that the virtual connectivity of Gnutella is anything like a Cayley tree is absurd, because it implies no closed paths. Consider: In order to discover and connect to a new a host on the Gnutella network, you need to catch a search request originating from that host. The fact that you were able to recieve that search request in the first place means that there was already a path between you and the remote host--therefore you have created at least one closed cycle by forming the new connection.
Telephones were invented to allow people to talk to each other over a distance. That includes phone sex. Photography was invented to record images--that includes sexual images. It's liek you're saying I can't use a hammer to drive stakes into the ground because it was only "invented for" driving nails into wood.
<wank>
Uhm, ATI has refuced to release the specs for several key features of their vodeo chipsets (notably the MPEG-decoding-related features of hardware IDCT and motion compentation.)
Consequently I have to reboot my laptop to a closed OS whenever I want to watch a DVD at more than 10 fps.
So, really, selling more iPods isn't the point. Selling more Macs is. Thus the Mac-centeredness of the device.
You can just walk up and touch the things you know...
Yeah. Hook a big electromagnet to your house mains and wave it at your hard drive. Not only will it hum audibly when connected to AC current, but when you try to read your data you will find out first hand about electromagnetic noise.
Now imagine a fan with rapidly spinning and switching magnets sitting on top of a next-generation CPU with such a fine process that only two or three electrons constitute the difference between a "1" and a "0". Are you beginning to see the problem?
The problem with incrementals, as you point out, is that you tend to scatter the important data across a bunch of disks and tapes. But a good algorithm can keep the disk set down.
Since a CDR is fixed-size and write-once, there will usually be a sizable chunk of space left over after getting the changes. You can use the extra space to trim the size of your restore set--say, after computing the diff for this week, the software decides that it needs to use 350 MB to back up all of this week's changes. Then it looks at its database and sees that all but 280 MB of data on some previous disc has been obsoleted. Then it simply copies that 280MB over again onto the new disk, and tells you you can throw away the old disk. That way you can limit the maximum size of the restore set. You can also occasionally burn consolidation discs that condense the non-obsoleted data from a bunch of discs onto one. The discs should never be on average more than 50% obsolete if you do it right, and that puts a hard cap on the size of the disc collection you have to keep.
Also, in this particular question, it's a family server being backed up, not a corporate server--cheap is important, convenience and speed of backing up is important (because it's a hard habit to keep on a home computer,) and you can simply pay the kid a couple bucks to sit there and feed CDRs if/when you need to restore (I've been there too.)
That worked really well for backing up our 80MB drives onto stacks of 1.44MB floppies, since you would really only need to insert about 5-10 floppies during your weekly backup, just to get the files that changed.
So why not just do incremental backup onto CD-Rs? Even with 100GB of archives, most of those are static. You probably won't need to use more than one CDR per week (maybe two) to track the changes. It's cheap, relatively painless if you've got the right software (and it wouldn't be hard to throw together incremental backup/recovery scripts in Perl if you're into that sort of thing.) and you've probably already got a CD burner.
If less than 650MB of files change in a week, the rest of the CDR can be filled up with files that were on earlier CDRs (this way your backup set can remain finite and you can throw out the earlier CDRs as they become obsolete. Or if you keep them all, you can reconstruct that state of your hard drive at *any* time, not just at the last backup.) This seems ideal to me--why is everyone else talking about expensive solutions like tape drives, DVD-RWs, and second hard drives?
If the fan were going to make 40Khz noise, that would indicate that there is a process which takes on the same configuration only once every revolution. This is not the case here; the system looks the same 12 times every revolution. So the sound produced is at 480 KHz.
Your orchestra example is also bogus. If you were to take the sound of a violin playing one note, and layer on 11 more copies of the same sound, all being out-of-phase with each other by 1/12 cycle (which is what we have with the fan), you would *not* hear the original sound. You would hear the 12th harmonic of the volin, and all multiples thereof. In DSP books, it's called a comb filter.
So he can do that.
Compare the numbers here to the numbers here and be aware that on LCDs, contrast ratio comes at a premium price--there's no way you're going to get a $400 LCD with comparable contrast to a $100 CRT.
And you're forgetting about color gamut entirely, which is just as important. LCDs have terrible color range compared to CRTs.
From personal experience, that isn't likely. All the good a 40-second buffer does you is that you can jostle a player for 40 seconds before it starts to skip. When jogging, you are continually jostling the player. That means you can jog for 40 seconds without incurring a skip, but after that, it's over. You can definitely walk around with them, but running is out of the question.
The roads out near my house are packed dirt which is heavily prone to washboarding. While most car and portable CD players have decent skip protection, I haven't seen one that could handle being driven over these roads for more than a minute.
Still, the result was disappointing at best. I learned a couple of things:
But the ultimate lesson is that people have an amazing tendency not to be able to learn from other people's mistakes. Unless they're so far gone that they think they actually gained anything by camping out for Episode 1...
When people speak, it is the consonants that matter. Ever try listening closely to someone with a pronounced regional accent? The vowels are all jumbled up but the speech is still intelligible. IIRC, people tried to teach gorillas to communicate using different grunts, and gave up in favor of sign language. Reason being that you *can't* string two different vowels together without a consonant in between and have it be intelligible.