However, you can't sell that in the US, because US consumers are already protected against credit card fraud by law.
And whether you realize it or not, we pay through the nose for it in the form of high interest rates and taxes. Yes, the government prosecutes credit card fraud, and it's rampant in the US. The credit card companies have no interest in implementing more secure methods of transaction because the costs of their lacking security are shouldered by the government.
I want secure, encrypted electronic money, and I want it now. There's no reason we couldn't have had this 20 years ago. It won't happen in the private sector though, they have to make money. And I don't want to have to pay money in order to use my money. And then there's the chicken-and-egg problem with elecronic money you mention. It's going to take government action to make it happen. I'm not holding my breath.
The only obstacle to this is the fact that our OEM agent only supports Windows products.
Someone explain to me what this means...you guys have a program which runs on windoze and linux, right? Your "OEM agent" presses CD's, manufactures boxes, and puts them in stores, right?
Now, WTF does the "OEM Agent" care what's on the damn CD? You guys do all the software, right?
No, counting experiments are poisson, and that's exactly what this is. We've been producing wacky particles in accelerators for years, and trust me, someone would have noticed if the wrong distribution was being used for a particular thing. To do a naieve analysis, say the standard model predicts 0.5 events, and you see 3 events. You can read off the poisson distribution to see what the probability of this is.
But let's say you check the poisson probability of each event. Let's further assume you only look at the events that have a high probability of being signal (i.e. the ones at high reconstructed mass^2 of the higgs). Further, the number of events you see is less than 5. This is in the realm of small statistics, and contaminated by mismeasurement of lower-energy events, of which there are many.
I also know that the Aleph team used a lot of fancy statistics to get the maximum sigma they could out of a handful of events (there are only ~3 events that are driving the estimation of sigma up). Nevertheless, there are only 3 events. Personally, I don't care what sigma they claim to have. I won't believe it until the number of events is >~ 100. Flip a coin twice. Did you get heads twice (or tails twice)? maybe. Is this meaningful? no. It's small statistics.
Notice also that IIRC the three sigma result was data from one detector.
I think it was almost 4 sigma from the Aleph detector that was driving the result. The NYT article is referring to data from the other detectors that has now been added in, driving the total significance down a bit to around 3 sigma.
Surely LHC will not be much cleaner than the experiment at Fermilab... doesn't H stand for Hadron? Anyway, computers get faster all the time which allows for much more sophisticated cuts and analysis to deal with the horrendous background.
Yes, H=Hadron (meaning proton). Fermilab is also a proton machine. The LHC will be the messiest machine ever built, worse than Fermilab due to the higher energy. Oh, actually, I think RHIC is probably the messiest machine ever built. Take a look at these event displays. One of them has almost 9000 tracks in one event! Looking at these makes me glad to be in theory!
...but we saw hints that it might be there. The community never claimed to have discovered it either, so the "discovery" is not in question. See, in physics we require "five sigma" to claim a discovery. What does that mean? If you have a bell curve (gaussian), the data you see has to be five standard deviatiations away from what you would expect in the absence of the higgs. We didn't get there, the latest review of the CERN data puts it around three sigma. It's worth noting that three-sigma statistical fluctuations aren't uncommon in physics. In fact, the search for the Higgs boson has seen three sigma excesses before that turned out to be nothing.
Compare that to your sociologists and political pollsters who claim that 55% agreement is profoundly important. Five sigma corresponds to a probability of 0.02% that what you saw could have been background (non-higgs) rather than signal (higgs).
It's just painful to wait because the LEP2 accelerator at CERN was very clean (electron-positron collisions), and extracting the higgs signal was relatively straightforward. At Fermilab, they will be able to see it if the mass is where CERN says it is, but it will be much more difficult (proton-antiproton collisions -- very messy). In any case, it will be several more years before we know for sure. If LEP2 had run just a little bit longer, we would have known.
At any rate, even if Fermilab doesn't see it, the new accelerator at CERN, the LHC, will see it. But it might be 8 years before we know. And if we don't see it...we theorists have some serious work to do.
IBM has an absolutely dismal history in marketing. If you want to know how to take a technically superior product and kill it by not saying anything, look to IBM. I was an OS/2 user for years before switching to linux. Basically what it comes down to is that IBM goes to big corporate execs, and works with them to find a solution that is "best" for them. M$, on the other hand, makes lots of noise, flaps its wings, and dumps a lot of money into creating public opinion. IMHO M$ has one of the best marketing departments in the world.
IBM has no interest in blowing money on public opinion. It's not their gig. They sell big honking server iron. They don't care what runs on it. They've just got to sell that iron. Don't expect IBM to do dick for linux's public image, unless you count sales data and contributed software as part of the public image. (which is absolutely great of them...don't get me wrong)
Ok, you've gotta take Escape Velocity out of your sig. I mean it. It's a great game. But this is a linux site! (ok...sorta) It's pissing me off to be reminded that I can't play it any more. Anyway, since it looks like you might work at Ambrosia...how about a linux version! Open source would be nice (a la Maelstrom), but I'll pay for it!
You're absolutely right, I should have thought about it a little more before blabbing that I don't notice interference.
But anyway, you don't really want a QED renderer. Imagine rendering a soap bubble. In order to get an accurate shifting-rainbow effect, you'd have to model extremely subtle air currents, and the thickness of the film in micrometers. It's far more efficent to take your usual surface and apply a time-varying texture to it, and tweak it until it looks accurately like a soap film.
The computation required to accurately render QED is absurd. Instead it would be better to have a class of objects in your renderer (diffractors, thin films, etc) that can simulate diffraction. But don't expect those to behave nicely when they interact with non-diffracting objects, the computing required would just be too huge. If you could do that, it's time to start coding The Matrix.
How often, in every day life, do you notice diffraction and interference? I never do. Consider also that the size of objects which cause diffraction are the same order of magnatude in size as the wavelength of light (i.e. 10^-7m). Which, BTW, is far smaller than you can see. Now imagine you're going to keep track of polygons/voxels 10^-7 in size, for a room that's 10m by 10m by 3m. That's 10*10*3/(10^-7)^3 =~ 3*10^23 voxels to keep track of. Forget it. There are far better ways to simulate diffraction, if you really wanted it.
What I have seen, that's really cool, are Relativisticraytracing. Do that Nsuck^H^H^H^Hvidia!
That's all fine and well, but what if java is not a language they will ever use in the "real world". The replacement of introductory courses from C++ to java has left everyone that is not a CS geek in the dust.
In scientific computing, speed is paramount. Most people use fortran. Many would like to get away from fortran because it's over thirty years old, and has none of the nice features of newer languages. But for non-CS people, C++ is not something you pick up on a whim. C++ is by far the most complicated language around. The world of scientific computing, I fear, will be stuck with fortran forever because of its lower learning curve, and because of the fact that The bastards have stopped teaching C++ altogether. Java, while nicer in some regards, does not easily lead to picking up C++ (mostly, I think, due to templates and STL). Taking an intro java class and using fortran works though, because the language constructs needed for fortran are few, and certainly contained as a (small) subset of java.
So I think teaching java is a horrible turn of events for we mere mortals. It has too many variants, is not (and will not be) standardized. And most importantly, most places only have one language class. That language should be the one that is most common, and contains enough language elements to allow people to easily transition to most other languages. Going from C++ to java is easy. Going the other way is nearly impossible.
Maybe when more compilers correctly implement the C++ standard the situation will improve. These days it's very hard to compile on different platforms because different vendors implement different subsets of the standard. That, and they have to make STL errors readable. A newbie is not going to sift through a page of horrible looking errors from a single template mistake, just to find that none of the errors tell him what (or where) he did wrong!
FilterProxy can remove web bugs by stripping them straight out of the html. Oh, and it removes ads too.
</plug>
--Bob
Re:Tabletop accelerators - was Re:The trouble with
on
Antimatter Propulsion
·
· Score: 1
Well, the key phrase in the article you link is "Energy of a million of volts", or 1 MeV (using particle physics units here). An electron weighs approximately 1/2 MeV, and a proton weighs about 1000 MeV. So if if you wanted to use this new laser acceleration technique, you'd need roughly 1000 of them in a row...needless to say, that's no longer a "tabletop" accelerator. And you'd need to put even more energy into the accelerated protons if you want to get anti-protons, since the probability of generating an anti-proton is so low, and because of the kinematics of fixed target collisions.
The laser accelerator you link sounds very interesting, and if it becomes widely used, my wild guess is that it could reduce the cost of the accelerator by maybe an order of magnatude (if you're lucky). But we're still talking a huge chunk of change, and then there's all the hardware to collide the beam with a fixed target and filter the products for anti-protons, the cost of which isn't changed by having a cheaper accelerator.
The article you linked to produces positrons from photons (femtosecond lasers), which is easy since at high energy a photon will split directly into an electron and positron. Antiprotons weigh 2000 times more than a positron (electron), and they're not fundamental particles. Even if you dumped enough energy into the laser to make antiprotons, you'd get mostly pions, etas, rhos, kaons, etc...and very few antiprotons. Photon "colliders" that would do exactly this are currently under study. But trust me, it wouldn't be an efficent source of antiprotons.
Antiprotons are currently created by slamming a proton beam into a fixed target (Beryllium, IIRC), which creates a shower of hadronic junk. A very small fraction of that is antiprotons. The junk is filtered to keep the antiprotons, and dump the rest. It's an extremely inefficent and expensive process.
Ok, I just checked out TeXmacs. This is really cool, thanks for the pointer. And it does anti-aliased fonts! Is it using TeX rendering to render the entire user interface? The interface is really pretty. And it has CAS backends for Maxima and GiNaC! Wow!
I have used LyX also (front end for LaTeX), and it is quite good. It's math-entry and rendering is the best I've seen yet in a user interface. My girlfriend now uses it exclusively to write papers (beats the crap out of bloated M$ Word or Staroffice). I usually use straight TeX for my papers and presentations so I can manipulate things at a lower level, and use some macros developed by/for physics people.
As to extending graphitti, I'd think that this would be a losing proposition. After adding strokes for the roman alphabet, greek alphabet, hebrew alphabet, numbers, and symbols, you might as well have just tried to recognize the symbols in the first place. I think for a tablet the easiest thing to do would be to have an "input" area that is very large (i.e. write very large) that then gets recognized and transferred to the document. The input area should draw a vector-graphic with your pen strokes, and after the stroke is complete, attempt to recognize it after-the-fact, allowing for you to correct it. (maybe tap on the incorrectly-recognized letter and have it bring up a list of nearest matches)
I have found graphitti less than perfect for most of my needs. I prefer to type. I'm not sure how much extra work scientists would be willing to put up with in entering formulas. I mean, usually there's a "bigger picture" in the back of your mind, trying to work out the calculation. If you have to interrupt your thought process a whole bunch to enter the formula in a way the computer can handle, you've lost the advantage of putting it on the computer in the first place. Attempting to recognize existing math and notations would be a big win.
I've been having fantasies about a tablet computer for over a year now. I want something that isn't too much larger or heavier than a large tablet of paper, and combines pen-input with a computer interface. I'm talking handwriting recognition, gesture recognition, and most importantly, a headphone jack and mp3-playing software.
The hardware exists...a 11" TFT LCD screen, Wacom-like pen input overlaid on top. It needs to have a high resolution (both the screen and input) for accurate handwriting recognition. Wouldn't need a very fast processor. Could sync to my computer over USB.
As a theoretical physicist, I desparately want something like this. I'm a massive computer junkie, but currently, the highest-tech way I can do calculations is pencil and paper... On the math side, recognizing mathematical notation will be very hard, and would require a lot of work in user interfaces. In the short term, just recording the user's penstrokes and saving it as a vector graphic would be sufficent. In the long term, interface it to a basic Computer Algebra System. i.e. something that will check all those factors of two, negative signs, etc. In the very long term, have the interface do most of what I do by hand. For instance, apply a mathematical identity to an equation, and copy the new equation to the next line. Allow me to manipulate individual terms. Most of all, allow me to define new notations. Each sub-field of math, physics, chemistry, and engineering uses its own notation, and a rule-system should exist to check the validity of the input in the notation that is familiar to the user.
Right now I use pencil and paper, some Maple, and computer programs to numerically evaluate things. Maple's interface is not well suited to a pen-based manipulation system. (don't mention Mathematica, I will not professionally support their absurd pricing and draconian licensing policies) I have high hopes that a viable open-source Computer Algebra System will evolve out of the existing Octave or GiNaC.
*Sigh* if any of you entreprenuring business types are listening, WE WANT TABLETS AND WE WANT THEM YESTERDAY. And not those stupid web-browser tablets. sheesh.
The idea is that RPM itself would install a modified/bin/install, that has the same interface as the "standard" one(s). That way programs don't have to know or care whether they're on an rpm system or not, but RPM systems would automagically get entries in their databases whenever a 'make install' uses/bin/install.
Downtown St. Genis Ha! It's a one stoplight town! Downtown consists of that little grocery store, the pub, and a restaurant or two.;)
Well after living in St. Genis for a summer, I came back to Madison, WI, where the neutrino beam from the MINOS experiment is passing right below us! The beam goes from Fermilab (Batavia, IL) to somewhere in minnesota, and goes right under us in Madison! If anyone has the opportunity to take a tour of the NuTeV experiment at Fermilab, you can walk right through the neutrino beamline, which is kinda fun.
I haven't seen anyone mention the Amanda Experiment, which is just plain cool because it's in Antarctica. They're putting their detector in the antarctic ice, again at a depth of about 2km (they use hot water drills).
The biggest problem I've had with rpm, IMNSHO, is its inability to deal with dependancies of non-rpm packages on the
system. I don't mind having to go root around for my rpm updates, in fact I prefer this so these benefits for apt-get
aren't of great concern to me.
Recent RPM (4.0) can do this to some extent, I think. But here's a better idea:
Modify/bin/install to insert entries into the RPM database for the individual files that are installed. Then rpm doesn't have to root through your filesystem trying to guess where you installed openssl. It would be even better if autoconf could grab a little info from the.spec file that came with the package, and pass the basic package info to/bin/install, that way doing the equivalent of a 'rpm --rebuild ; rpm -U ' when you do a make install. I sometimes find that I have to hack the source, or pass extra options to./configure to get something to compile. Then using rpm to create a binary package from a hacked source tree is a real pain. (rpm only wants to create packages from.tar.gz or.src.rpm, and if they don't compile, it just sucks).
Of course, there's also the option of using unflattering or offensive names like:
Junk
Crap
Bunk
WillBreakAsSoonAsYouGetIt
Scum
Crud
etc. This has the nice added bonus of being a slap in the face to all the commercial products with advertisers scratching their heads trying to come up with "catchy" names and jingles for them. While you're at it, make your offensive name be a recursive acronym too:
Don't forget about my personal entry to the field, FilterProxy, which does use HTTP/1.1.;)
I've considered porting the whole lot to mozilla, and probably will someday. I'd like to be able to take advantage of Mozilla's parser to do the filtering. Right now the HTML has to be parsed twice; once for the proxy, and once for the browser.
I highly recommend the Diamond Rio. It has drivers in the kernel that work very well (on sourceforge), a graphical (gtk) file manager thingy (here), and there's even a utility to change the startup animation! (here)
So...how is SiCAS (Sinusoidal Coding) different from a simple fourier transform, which is already used in the compression of MP3/AAC?
Just a thought, but it might be interesting to write a codec that would create a MOD/STM like file. That is, identify instruments, sample them, then encode the music as a sequence of notes (as MOD's/STM's do). You'd also need a delta track to encode differences from the MOD (i.e. bending notes on a guitar, vibrato, voice). By trying to encode it as a MOD/STM you could remove wide frequency bands filled with instruments from being encoded. Then again, the delta track might be bigger than an equivalent mp3. And identifying instruments would probably be very computationally intensive. But interesting.
Try disabling the video ROM bios shadow option. It improved things considerably for me. It will still crash occasionally (once every 1-6 hours). It definately crashes more often under linux though (2.4.0-test12 + latest NVidia drivers), so hopefully NVidia will get off their ass and release a newer driver.
I've done a number of things to improve the situation (disabling AGP 4x, don't remember if I disabled video ROM shadow). But it still locks hard. It looks like a PCI bus hang...sound plays in circles, not responding to interrupts. The game is Terminus, and I can play it for about 1/2 hour. But nothing pisses me off more than having to hit the reset button. There's a reason I don't use windoze! One of the reasons windoze crashes so much is that it lets crappy third-party code run in ring 0 (kernel mode) -- vxd's and drivers. And this is exactly why we don't want third parties distributing binary-only drivers which can hose my kernel! (like Nvidia).
This is with 2.4.0-test9, X 4.0.1a (RH7 default). Also tried with kernel 2.2.17. Anyone tried X 4.0.2 yet on this?
Slashdot Mirror
And whether you realize it or not, we pay through the nose for it in the form of high interest rates and taxes. Yes, the government prosecutes credit card fraud, and it's rampant in the US. The credit card companies have no interest in implementing more secure methods of transaction because the costs of their lacking security are shouldered by the government.
I want secure, encrypted electronic money, and I want it now. There's no reason we couldn't have had this 20 years ago. It won't happen in the private sector though, they have to make money. And I don't want to have to pay money in order to use my money. And then there's the chicken-and-egg problem with elecronic money you mention. It's going to take government action to make it happen. I'm not holding my breath.
--Bob
Now, WTF does the "OEM Agent" care what's on the damn CD? You guys do all the software, right?
--Bob
But let's say you check the poisson probability of each event. Let's further assume you only look at the events that have a high probability of being signal (i.e. the ones at high reconstructed mass^2 of the higgs). Further, the number of events you see is less than 5. This is in the realm of small statistics, and contaminated by mismeasurement of lower-energy events, of which there are many.
I also know that the Aleph team used a lot of fancy statistics to get the maximum sigma they could out of a handful of events (there are only ~3 events that are driving the estimation of sigma up). Nevertheless, there are only 3 events. Personally, I don't care what sigma they claim to have. I won't believe it until the number of events is >~ 100. Flip a coin twice. Did you get heads twice (or tails twice)? maybe. Is this meaningful? no. It's small statistics.
--Bob
I think it was almost 4 sigma from the Aleph detector that was driving the result. The NYT article is referring to data from the other detectors that has now been added in, driving the total significance down a bit to around 3 sigma.
Yes, H=Hadron (meaning proton). Fermilab is also a proton machine. The LHC will be the messiest machine ever built, worse than Fermilab due to the higher energy. Oh, actually, I think RHIC is probably the messiest machine ever built. Take a look at these event displays. One of them has almost 9000 tracks in one event! Looking at these makes me glad to be in theory!
--Bob
Compare that to your sociologists and political pollsters who claim that 55% agreement is profoundly important. Five sigma corresponds to a probability of 0.02% that what you saw could have been background (non-higgs) rather than signal (higgs).
It's just painful to wait because the LEP2 accelerator at CERN was very clean (electron-positron collisions), and extracting the higgs signal was relatively straightforward. At Fermilab, they will be able to see it if the mass is where CERN says it is, but it will be much more difficult (proton-antiproton collisions -- very messy). In any case, it will be several more years before we know for sure. If LEP2 had run just a little bit longer, we would have known.
At any rate, even if Fermilab doesn't see it, the new accelerator at CERN, the LHC, will see it. But it might be 8 years before we know. And if we don't see it...we theorists have some serious work to do.
--Bob
IBM has an absolutely dismal history in marketing. If you want to know how to take a technically superior product and kill it by not saying anything, look to IBM. I was an OS/2 user for years before switching to linux. Basically what it comes down to is that IBM goes to big corporate execs, and works with them to find a solution that is "best" for them. M$, on the other hand, makes lots of noise, flaps its wings, and dumps a lot of money into creating public opinion. IMHO M$ has one of the best marketing departments in the world.
IBM has no interest in blowing money on public opinion. It's not their gig. They sell big honking server iron. They don't care what runs on it. They've just got to sell that iron. Don't expect IBM to do dick for linux's public image, unless you count sales data and contributed software as part of the public image. (which is absolutely great of them...don't get me wrong)
--Bob
--Bob
But anyway, you don't really want a QED renderer. Imagine rendering a soap bubble. In order to get an accurate shifting-rainbow effect, you'd have to model extremely subtle air currents, and the thickness of the film in micrometers. It's far more efficent to take your usual surface and apply a time-varying texture to it, and tweak it until it looks accurately like a soap film.
The computation required to accurately render QED is absurd. Instead it would be better to have a class of objects in your renderer (diffractors, thin films, etc) that can simulate diffraction. But don't expect those to behave nicely when they interact with non-diffracting objects, the computing required would just be too huge. If you could do that, it's time to start coding The Matrix.
--Bob
You're kidding, right?
How often, in every day life, do you notice diffraction and interference? I never do. Consider also that the size of objects which cause diffraction are the same order of magnatude in size as the wavelength of light (i.e. 10^-7m). Which, BTW, is far smaller than you can see. Now imagine you're going to keep track of polygons/voxels 10^-7 in size, for a room that's 10m by 10m by 3m. That's 10*10*3/(10^-7)^3 =~ 3*10^23 voxels to keep track of. Forget it. There are far better ways to simulate diffraction, if you really wanted it.
What I have seen, that's really cool, are Relativistic ray tracing. Do that Nsuck^H^H^H^Hvidia!
--Bob
In scientific computing, speed is paramount. Most people use fortran. Many would like to get away from fortran because it's over thirty years old, and has none of the nice features of newer languages. But for non-CS people, C++ is not something you pick up on a whim. C++ is by far the most complicated language around. The world of scientific computing, I fear, will be stuck with fortran forever because of its lower learning curve, and because of the fact that The bastards have stopped teaching C++ altogether. Java, while nicer in some regards, does not easily lead to picking up C++ (mostly, I think, due to templates and STL). Taking an intro java class and using fortran works though, because the language constructs needed for fortran are few, and certainly contained as a (small) subset of java.
So I think teaching java is a horrible turn of events for we mere mortals. It has too many variants, is not (and will not be) standardized. And most importantly, most places only have one language class. That language should be the one that is most common, and contains enough language elements to allow people to easily transition to most other languages. Going from C++ to java is easy. Going the other way is nearly impossible.
Maybe when more compilers correctly implement the C++ standard the situation will improve. These days it's very hard to compile on different platforms because different vendors implement different subsets of the standard. That, and they have to make STL errors readable. A newbie is not going to sift through a page of horrible looking errors from a single template mistake, just to find that none of the errors tell him what (or where) he did wrong!
--Bob
FilterProxy can remove web bugs by stripping them straight out of the html. Oh, and it removes ads too.
</plug>
--Bob
The laser accelerator you link sounds very interesting, and if it becomes widely used, my wild guess is that it could reduce the cost of the accelerator by maybe an order of magnatude (if you're lucky). But we're still talking a huge chunk of change, and then there's all the hardware to collide the beam with a fixed target and filter the products for anti-protons, the cost of which isn't changed by having a cheaper accelerator.
--Bob
Antiprotons are currently created by slamming a proton beam into a fixed target (Beryllium, IIRC), which creates a shower of hadronic junk. A very small fraction of that is antiprotons. The junk is filtered to keep the antiprotons, and dump the rest. It's an extremely inefficent and expensive process.
--Bob
--Bob
I have used LyX also (front end for LaTeX), and it is quite good. It's math-entry and rendering is the best I've seen yet in a user interface. My girlfriend now uses it exclusively to write papers (beats the crap out of bloated M$ Word or Staroffice). I usually use straight TeX for my papers and presentations so I can manipulate things at a lower level, and use some macros developed by/for physics people.
As to extending graphitti, I'd think that this would be a losing proposition. After adding strokes for the roman alphabet, greek alphabet, hebrew alphabet, numbers, and symbols, you might as well have just tried to recognize the symbols in the first place. I think for a tablet the easiest thing to do would be to have an "input" area that is very large (i.e. write very large) that then gets recognized and transferred to the document. The input area should draw a vector-graphic with your pen strokes, and after the stroke is complete, attempt to recognize it after-the-fact, allowing for you to correct it. (maybe tap on the incorrectly-recognized letter and have it bring up a list of nearest matches)
I have found graphitti less than perfect for most of my needs. I prefer to type. I'm not sure how much extra work scientists would be willing to put up with in entering formulas. I mean, usually there's a "bigger picture" in the back of your mind, trying to work out the calculation. If you have to interrupt your thought process a whole bunch to enter the formula in a way the computer can handle, you've lost the advantage of putting it on the computer in the first place. Attempting to recognize existing math and notations would be a big win.
--Bob
The hardware exists...a 11" TFT LCD screen, Wacom-like pen input overlaid on top. It needs to have a high resolution (both the screen and input) for accurate handwriting recognition. Wouldn't need a very fast processor. Could sync to my computer over USB.
As a theoretical physicist, I desparately want something like this. I'm a massive computer junkie, but currently, the highest-tech way I can do calculations is pencil and paper... On the math side, recognizing mathematical notation will be very hard, and would require a lot of work in user interfaces. In the short term, just recording the user's penstrokes and saving it as a vector graphic would be sufficent. In the long term, interface it to a basic Computer Algebra System. i.e. something that will check all those factors of two, negative signs, etc. In the very long term, have the interface do most of what I do by hand. For instance, apply a mathematical identity to an equation, and copy the new equation to the next line. Allow me to manipulate individual terms. Most of all, allow me to define new notations. Each sub-field of math, physics, chemistry, and engineering uses its own notation, and a rule-system should exist to check the validity of the input in the notation that is familiar to the user.
Right now I use pencil and paper, some Maple, and computer programs to numerically evaluate things. Maple's interface is not well suited to a pen-based manipulation system. (don't mention Mathematica, I will not professionally support their absurd pricing and draconian licensing policies) I have high hopes that a viable open-source Computer Algebra System will evolve out of the existing Octave or GiNaC.
*Sigh* if any of you entreprenuring business types are listening, WE WANT TABLETS AND WE WANT THEM YESTERDAY . And not those stupid web-browser tablets. sheesh.
--Bob
The idea is that RPM itself would install a modified /bin/install, that has the same interface as the "standard" one(s). That way programs don't have to know or care whether they're on an rpm system or not, but RPM systems would automagically get entries in their databases whenever a 'make install' uses /bin/install.
Well after living in St. Genis for a summer, I came back to Madison, WI, where the neutrino beam from the MINOS experiment is passing right below us! The beam goes from Fermilab (Batavia, IL) to somewhere in minnesota, and goes right under us in Madison! If anyone has the opportunity to take a tour of the NuTeV experiment at Fermilab, you can walk right through the neutrino beamline, which is kinda fun.
I haven't seen anyone mention the Amanda Experiment, which is just plain cool because it's in Antarctica. They're putting their detector in the antarctic ice, again at a depth of about 2km (they use hot water drills).
--Bob
Modify /bin/install to insert entries into the RPM database for the individual files that are installed. Then rpm doesn't have to root through your filesystem trying to guess where you installed openssl. It would be even better if autoconf could grab a little info from the .spec file that came with the package, and pass the basic package info to /bin/install, that way doing the equivalent of a 'rpm --rebuild ; rpm -U ' when you do a make install. I sometimes find that I have to hack the source, or pass extra options to ./configure to get something to compile. Then using rpm to create a binary package from a hacked source tree is a real pain. (rpm only wants to create packages from .tar.gz or .src.rpm, and if they don't compile, it just sucks).
--Bob
Working on it...will move to HTML::Embperl soon.
- Junk
- Crap
- Bunk
- WillBreakAsSoonAsYouGetIt
- Scum
- Crud
etc. This has the nice added bonus of being a slap in the face to all the commercial products with advertisers scratching their heads trying to come up with "catchy" names and jingles for them. While you're at it, make your offensive name be a recursive acronym too:- Software
- haplessly
- iilluminating
- turds
For, say, a spam filter.--Bob
I've considered porting the whole lot to mozilla, and probably will someday. I'd like to be able to take advantage of Mozilla's parser to do the filtering. Right now the HTML has to be parsed twice; once for the proxy, and once for the browser.
--Bob
--Bob
Just a thought, but it might be interesting to write a codec that would create a MOD/STM like file. That is, identify instruments, sample them, then encode the music as a sequence of notes (as MOD's/STM's do). You'd also need a delta track to encode differences from the MOD (i.e. bending notes on a guitar, vibrato, voice). By trying to encode it as a MOD/STM you could remove wide frequency bands filled with instruments from being encoded. Then again, the delta track might be bigger than an equivalent mp3. And identifying instruments would probably be very computationally intensive. But interesting.
--Bob
I've done a number of things to improve the situation (disabling AGP 4x, don't remember if I disabled video ROM shadow). But it still locks hard. It looks like a PCI bus hang...sound plays in circles, not responding to interrupts. The game is Terminus, and I can play it for about 1/2 hour. But nothing pisses me off more than having to hit the reset button. There's a reason I don't use windoze! One of the reasons windoze crashes so much is that it lets crappy third-party code run in ring 0 (kernel mode) -- vxd's and drivers. And this is exactly why we don't want third parties distributing binary-only drivers which can hose my kernel! (like Nvidia).
This is with 2.4.0-test9, X 4.0.1a (RH7 default). Also tried with kernel 2.2.17. Anyone tried X 4.0.2 yet on this?
--Bob