I've been working on a driver for an embedded PPC, and referring to the companion book "Linux Device Drivers 3rd ed", and one of the things that struck me about it was the implicit assumptions that: 1) All the world is an X86 2) All the world's devices are on either PCI, ISA, or USB.
There were no descriptions about non-X86 device, no descriptions about devices NOT on a PCI bus (e.g. embedded devices on-chip peripherals).
Does this book talk about any non-x86 arch issues?
I don't use any of the customization or personalization features of the news sites I visit, simply because to do so requires me to be tracked by the site, and I don't wish to provide ANY site with any more data about me than I must.
"people who could afford to found their own personal corporation would have double the voting power of those who could not afford it.
In fact, someone wealthy could found thousands of corporations just to get more votes."
Gosh, I'm so glad you said that, because nobody else in this thread said anything like that! Nobody said "Yes, if 'corporations' could vote, then you'd see the Rich And Powerful creating millions of shell corporations to increase their own voting power."
Oh wait, my bad - I said that in the very comment you are replying to!
Consider the following: What if a corporation were allowed to vote - one corporation, one vote. How much would that change things, when there are millions of people voting? Indeed, if we could limit the influence of a corporation down to just one vote, that would likely be better than what we have now, where a corporation can influence millions of votes via "soft money" funding of political parties.
In reality, it's not the idea that "corporations can vote" - it's the idea that "rich people, via corporations, can vote more than their fair share". Yes, if "corporations" could vote, then you'd see the Rich And Powerful creating millions of shell corporations to increase their own voting power.
But if I could limit [Koch|Microsoft|Ford|BP|..] to just ONE vote....
Considering that the KCSC has the largest collection of Russian gear outside of Moscow, and is one of the top space artifact restoration sites in the world, it really is the most logical choice.
I whole-heartedly agree with you - and I'll make another point. Much of what auto* was designed to do was to allow porting the Gnu toolchain over to a target which did not have it - e.g. porting binutils and GCC to some Unix box that did not have them yet, thus they had to assume as little about the target system as possible to allow bootstrapping. However, the idea was that once you HAD binutils, GCC, and libc, you could use them, and have a predictable standard environment.
Now-a-days, that is almost a gimme - any new system will almost certainly have GCC as a part of the bring-up. So why not move on to a pkg-config style system, where there is an executable that can be run for the target platform, that can answer questions like "How big is a pointer? an int? A float? Do you have these library routines? What do I do to dynamically link a program?" pkg-conf does a wonderful job for the programs it knows about, why not extend it to answer all the myriad of standard questions that auto* seems to ask every time it's run?
Sure, you'd have to generate that program for a new target - but guess what? most of the "questions" are ones GCC already knows the answer to, so why not just make GCC be the "pkg-config" for basic CPU arch type questions? Then, even if I am cross-compiling for a Floobydust300 rev B processor, all I have to do is 'floobydust-unknown-linux-gcc --whatis "sizeof(int)"' and I have my answer. (alternatively, dump an XML file, or a key=value file, or header, or any number of other approaches).
Re:Cross-platform, but not cross-compiling
on
Autotools
·
· Score: 2, Insightful
Now, configure something like CORBA targeting a PPC, but configuring on an X86, for compilation on an X86 using a cross compiler.
Oops - all your structure padding code for the CORBA martialling is broken, because the autoconf scripts all assume they can find out the padding of the structures by emitting a program, building it, running it (whoops! wrong arch!) and getting the output.
It's all well and good if the program is trivial enough that it does no serious probing of the system, or if the configure host is the same CPU type as the target, but break that, and unless the project's configure script is set up to correctly detect a cross compile, to provide a set of configuration parameters you can provide on the command line to set the variables that would normally be inferred by probing, AND has the wit to refuse to run without you providing those parameters because it detected you are cross compiling, and you will NOT get a running program by default, NOR will you be able to get one without major surgery on the configuration data by hand.
Imagine you receive a message from LinkedIn. And imagine that it is spam. But I repeat myself.
Cross-platform, but not cross-compiling
on
Autotools
·
· Score: 1
I'll throw this bit of fuel on the flame-fest, in the form of a question:
Does anybody else find that Autotools based projects, while being very cross-platform, are almost impossible to actually cross-compile?
I do embedded systems work, and the embedded universe is moving to Linux as the kernel, and quite frequently a sub-set of the Gnu environment for the runtime. So you get things like BitBake, OpenEmbedded, and Angstrom, which attempt to enable you to build a complete system from sources. However, what all these environments do is run QEMU to emulate the target CPU in order to do the builds.
Now, that's stupid IMHO: I have this VERY FAST multi-core workstation, and I am 1) Throwing away all but one core, and 2) Hobbling that core emulating a completely different architecture (e.g. emulating an ARM to build for the OMAP). Much of the - I shall use the term "work" although a more bovine-scatological term springs unbidden to mind - involves writing "recipes" for BitBake to work around issues in Autotools.
Much of Autotools seems to me to assume that the machine building the code will be the machine running the code - or at least, a machine of the same type as the machine running the code. So all the Autotools "magic" to deduce structure layouts, word sizes, byte orders, and such all assume that you can a) compile the code using the host's C compiler, and b) Run the resulting probe programs on the host. Both of which are totally FALSE for cross-compiling.
I used to say that you could design a new CPU that nobody had ever seen, and once you ported Binutils, GCC, and Linux to it, you could build an entire functioning distro for it, just by iterating over the various source packages for and cross-compiling. I know better now: most of the source packages out there DO NOT cross compile worth a damn! They might BUILD NATIVELY on a wide range of architectures, but not cross-compile.
Both Digital Radio Mondale and IBOC (Ibiquity) are bad. Both require a host of patented codecs to run (go over to the DRM project page and look at the requirements to build it - DRM suffers from the classic design by committee issues.
But IBOC is worse: Ibiquity has, as a part of the required standard, that all transmissions SHALL be encrypted with a key you have to license from Ibiquity. If they don't like what you are doing, NO KEY FOR YOU! For example Griffin was going to offer a IBOC tuner on USB (their Radio Shark HD), that would have allowed you to record the bit stream for time shifting purposes. Ibiquity says "THOU SHALT NOT RECORD THE STREAM" - and Griffin had to cancel the Radio Shark HD (after they had announced it, BTW).
Read that last again: this isn't a "you MAY encrypt, if you want to" - this is "You SHALL encrypt. Get over it."
Personally, I'd rather see a truly Free solution out there, but where's the profit in that?
This sort of legislation is due to the "OMFG I KIN FEEL IT IN MY BWAIN!!!" tinfoil hat crowd, saying "RADIASION IZ KILLIN DE BEEZ!"
And since the vast majority of people don't see fit to have an opinion on this, the vocal moronity - err, minority - are all that is heard, and the politicians will bow to the herd to get votes.
The right answer IMHO would be for all the carriers to say "OK, fine - since you are too sensitive for our signals, we will remove them." Let us see what happens when Joe Ranknfile finds his precccisouuuussss cellphone doesn't work, and it is due to the tinfoil hat brigade and the spineless political hacks who covet their votes. Suddenly it won't be JUST the tinfoilers who are making themselves heard.
If, at the same time as they institute tiered data plans, Verizon also brings the price of tethering down, then I am in.
They have been using the argument that "tethering costs more because tethered users use more data" to justify charging US$60 for tethering vs. US$30 for smartphone use. If they go tiered, then logically that argument should be mooted, and they should bring the cost of tethering down.
Of course, this being Verizon, to make that actually happen would require the use of a Bambleweeny 57 Sub-meson brain, an atomic vector plotter, and a cup of very hot tea - none of which I happen to have on me at this time.
Is there a GStreamer plug-in available? I had to use GStreamer to stream radio from my house to a museum where we were doing an Amateur Radio demonstration (noise floor at the museum was -70dBm, with interfering carriers near the HF bands of over -30dBm), and was using Speex to do it, but I had to really fight with it to get a low enough latency. If Codec2 were to be a GStreamer plug-in by January I'd be a happy guy (yes, I'd offer to do the work, but I am drowning at work right now...)
"I'm sure the moon hoaxers would like to know whether or not it saw the American flag we left up there."
No, they would want to know that it didn't see the flag: Moon Hoaxer: Did it see the flag? Chinese Scientist: Well, it's not designed to see anything that small Moon Hoaxer (interrupting): DID IT SEE THE FLAG, YES OR NO? Chinese Scientist: No, but it wouldn't see Moon Hoaxer (interrupting): SEE I TOLD YOU ALL IT WAS A HOAX HERE'S PROOF.
What they wouldn't want to know would be if it did see the flag: Moon Hoaxer: Did it see the flag? Chinese Scientist: Actually, yes, here's the flag, here's the lander Moon Hoaxer (interrupting): FAKE! FAKE! YOU ARE JUST IN ON THE CONSPIRACY! FAKE!
"If this is supposed to supplant AMBE, why not AMBE2 or S(uper)AMBE?"
Because: 1) AMBE is trademarked by DVSI, Inc. You would be infringing upon that and be sued into oblivion. 2) This codec is not based on Multi-Band Excitation (IMBE - Improved Multi-Band Excitation. AMBE - Advanced Multi-Band Excitation). Naming it thus would be an error.
"But the Outsiders only went to We Made It because of a Puppeteer deployed starseed lure."
You beat me to it.
SO, the Puppeteers have hyperdrive, and so if they show up, open trading relations, so we don't have to wait for the Outsiders.
Offer to go to the galactic core, or do a close orbit around a neutron star in a GP3, or whatever, but get that hyperdrive.
(besides, who knows if they don't already have second quantum yet? Sure, they told Beowulf they just developed it, but for all we know they'd been sitting on it for centuries, too afraid to build it.).
I don't have the sample files, but the TIA test document I linked to in my previous post gives a lot of data on how they modeled the impairments - that might give you a start. If I happen to run across any of the samples (and can redistribute them) I'll let you know. You might also contact the TIA and see if you can get the WAV files from them.
As an interesting experiment, you might try reproducing a test I did on the IMBE vocoder used in APCO-25 Phase 1: take the first 10 seconds of Kansas's "Carry On Wayward Son" - the acapella vocal harmony - and run that through. IMBE went nuts on the signal - it sounded like you were listening through a fan. I think the closely related frequency components of the various voices were too much for it to handle.
In a QGP, for the time and distance scales in question (very short and very small), a quark can act as though it is free to move, like a dog on a rope in the yard - as long as it doesn't go very far, it can move freely without the rope (a string of gluons) yanking it around. Since the density of the QGP is very high, just being able to roam his yard is enough - there's plenty of things to chase/bark at/hump in his yard, he doesn't NEED to go beyond it, and his rope doesn't change his behavior.
However, as the QGP cools and expands, all the good stuff leaves the yard, and poor ol' DownBoy can't get at anything without running into the end of his rope.
So as long as all the neighborhood UpBitches, LeptonCats, W-kids, Z-leaves, and other things are squeezed into his yard, DownBoy has asymptotic freedom. Let things cool, and his gluon leash is cramping his style again.
Slashdot Mirror
"That's ok, the energy unit that they use is the kilohome:"
I'm sorry, but there's some resistance to your new units. Can we get them in old-school "Hoover Dams", please?
"Of course, we can't build anything that will maintain thrust equal to the force of gravity for long enough...."
All you need is a bit of wien from the Duchy of Grand Fenwick , or failing that, some monohydrazine.
I've been working on a driver for an embedded PPC, and referring to the companion book "Linux Device Drivers 3rd ed", and one of the things that struck me about it was the implicit assumptions that:
1) All the world is an X86
2) All the world's devices are on either PCI, ISA, or USB.
There were no descriptions about non-X86 device, no descriptions about devices NOT on a PCI bus (e.g. embedded devices on-chip peripherals).
Does this book talk about any non-x86 arch issues?
I don't use any of the customization or personalization features of the news sites I visit, simply because to do so requires me to be tracked by the site, and I don't wish to provide ANY site with any more data about me than I must.
"people who could afford to found their own personal corporation would have double the voting power of those who could not afford it.
In fact, someone wealthy could found thousands of corporations just to get more votes."
Gosh, I'm so glad you said that, because nobody else in this thread said anything like that! Nobody said "Yes, if 'corporations' could vote, then you'd see the Rich And Powerful creating millions of shell corporations to increase their own voting power."
Oh wait, my bad - I said that in the very comment you are replying to!
Consider the following: What if a corporation were allowed to vote - one corporation, one vote. How much would that change things, when there are millions of people voting? Indeed, if we could limit the influence of a corporation down to just one vote, that would likely be better than what we have now, where a corporation can influence millions of votes via "soft money" funding of political parties.
In reality, it's not the idea that "corporations can vote" - it's the idea that "rich people, via corporations, can vote more than their fair share". Yes, if "corporations" could vote, then you'd see the Rich And Powerful creating millions of shell corporations to increase their own voting power.
But if I could limit [Koch|Microsoft|Ford|BP|..] to just ONE vote....
"And airplanes, one of the two remaining major airline designers/manufacturers is Boeing, who is in the US."
And the other, Airbus, also has engineering offices in the US (pretty much splang in the middle of the US).
Considering that the KCSC has the largest collection of Russian gear outside of Moscow, and is one of the top space artifact restoration sites in the world, it really is the most logical choice.
I'm glad at least one /.er got the joke.
I wonder what the freight costs are from Moscow to Hutchinson?
I whole-heartedly agree with you - and I'll make another point. Much of what auto* was designed to do was to allow porting the Gnu toolchain over to a target which did not have it - e.g. porting binutils and GCC to some Unix box that did not have them yet, thus they had to assume as little about the target system as possible to allow bootstrapping. However, the idea was that once you HAD binutils, GCC, and libc, you could use them, and have a predictable standard environment.
Now-a-days, that is almost a gimme - any new system will almost certainly have GCC as a part of the bring-up. So why not move on to a pkg-config style system, where there is an executable that can be run for the target platform, that can answer questions like "How big is a pointer? an int? A float? Do you have these library routines? What do I do to dynamically link a program?" pkg-conf does a wonderful job for the programs it knows about, why not extend it to answer all the myriad of standard questions that auto* seems to ask every time it's run?
Sure, you'd have to generate that program for a new target - but guess what? most of the "questions" are ones GCC already knows the answer to, so why not just make GCC be the "pkg-config" for basic CPU arch type questions? Then, even if I am cross-compiling for a Floobydust300 rev B processor, all I have to do is 'floobydust-unknown-linux-gcc --whatis "sizeof(int)"' and I have my answer. (alternatively, dump an XML file, or a key=value file, or header, or any number of other approaches).
Now, configure something like CORBA targeting a PPC, but configuring on an X86, for compilation on an X86 using a cross compiler.
Oops - all your structure padding code for the CORBA martialling is broken, because the autoconf scripts all assume they can find out the padding of the structures by emitting a program, building it, running it (whoops! wrong arch!) and getting the output.
It's all well and good if the program is trivial enough that it does no serious probing of the system, or if the configure host is the same CPU type as the target, but break that, and unless the project's configure script is set up to correctly detect a cross compile, to provide a set of configuration parameters you can provide on the command line to set the variables that would normally be inferred by probing, AND has the wit to refuse to run without you providing those parameters because it detected you are cross compiling, and you will NOT get a running program by default, NOR will you be able to get one without major surgery on the configuration data by hand.
" sending massive volumes of spam email messages targeting LinkedIn users."
To paraphrase Mark Twain:
I'll throw this bit of fuel on the flame-fest, in the form of a question:
Does anybody else find that Autotools based projects, while being very cross-platform, are almost impossible to actually cross-compile?
I do embedded systems work, and the embedded universe is moving to Linux as the kernel, and quite frequently a sub-set of the Gnu environment for the runtime. So you get things like BitBake, OpenEmbedded, and Angstrom, which attempt to enable you to build a complete system from sources. However, what all these environments do is run QEMU to emulate the target CPU in order to do the builds.
Now, that's stupid IMHO: I have this VERY FAST multi-core workstation, and I am
1) Throwing away all but one core, and
2) Hobbling that core emulating a completely different architecture (e.g. emulating an ARM to build for the OMAP).
Much of the - I shall use the term "work" although a more bovine-scatological term springs unbidden to mind - involves writing "recipes" for BitBake to work around issues in Autotools.
Much of Autotools seems to me to assume that the machine building the code will be the machine running the code - or at least, a machine of the same type as the machine running the code. So all the Autotools "magic" to deduce structure layouts, word sizes, byte orders, and such all assume that you can
a) compile the code using the host's C compiler,
and
b) Run the resulting probe programs on the host.
Both of which are totally FALSE for cross-compiling.
I used to say that you could design a new CPU that nobody had ever seen, and once you ported Binutils, GCC, and Linux to it, you could build an entire functioning distro for it, just by iterating over the various source packages for and cross-compiling. I know better now: most of the source packages out there DO NOT cross compile worth a damn! They might BUILD NATIVELY on a wide range of architectures, but not cross-compile.
Both Digital Radio Mondale and IBOC (Ibiquity) are bad. Both require a host of patented codecs to run (go over to the DRM project page and look at the requirements to build it - DRM suffers from the classic design by committee issues.
But IBOC is worse: Ibiquity has, as a part of the required standard, that all transmissions SHALL be encrypted with a key you have to license from Ibiquity. If they don't like what you are doing, NO KEY FOR YOU! For example Griffin was going to offer a IBOC tuner on USB (their Radio Shark HD), that would have allowed you to record the bit stream for time shifting purposes. Ibiquity says "THOU SHALT NOT RECORD THE STREAM" - and Griffin had to cancel the Radio Shark HD (after they had announced it, BTW).
Read that last again: this isn't a "you MAY encrypt, if you want to" - this is "You SHALL encrypt. Get over it."
Personally, I'd rather see a truly Free solution out there, but where's the profit in that?
And here's the other half of the issue:
"... unless the company can prove absolute need."
Such proof being provided on the memo line of a check with a lot of zeros, made out to the politico's reelection fund.
Somehow, I would guess that if Verizon wanted a cell site at some location, there are, $hall we $say, way$ to $ee $omething like that happen$.
This sort of legislation is due to the "OMFG I KIN FEEL IT IN MY BWAIN!!!" tinfoil hat crowd, saying "RADIASION IZ KILLIN DE BEEZ!"
And since the vast majority of people don't see fit to have an opinion on this, the vocal moronity - err, minority - are all that is heard, and the politicians will bow to the herd to get votes.
The right answer IMHO would be for all the carriers to say "OK, fine - since you are too sensitive for our signals, we will remove them." Let us see what happens when Joe Ranknfile finds his precccisouuuussss cellphone doesn't work, and it is due to the tinfoil hat brigade and the spineless political hacks who covet their votes. Suddenly it won't be JUST the tinfoilers who are making themselves heard.
"Radio signal strength decays exponentially. "
No, it decays geometrically.
Exponential decay would be of the form P=An^d, where "d" is the distance, and A and n are constants.
The formula for free space losses is of the form P=Ad^2 - a geometrical loss.
"Did you mean granular?"
Naw, he meant glandular, as in, "Verizon wants to get you by the glands...."
If, at the same time as they institute tiered data plans, Verizon also brings the price of tethering down, then I am in.
They have been using the argument that "tethering costs more because tethered users use more data" to justify charging US$60 for tethering vs. US$30 for smartphone use. If they go tiered, then logically that argument should be mooted, and they should bring the cost of tethering down.
Of course, this being Verizon, to make that actually happen would require the use of a Bambleweeny 57 Sub-meson brain, an atomic vector plotter, and a cup of very hot tea - none of which I happen to have on me at this time.
Is there a GStreamer plug-in available? I had to use GStreamer to stream radio from my house to a museum where we were doing an Amateur Radio demonstration (noise floor at the museum was -70dBm, with interfering carriers near the HF bands of over -30dBm), and was using Speex to do it, but I had to really fight with it to get a low enough latency. If Codec2 were to be a GStreamer plug-in by January I'd be a happy guy (yes, I'd offer to do the work, but I am drowning at work right now...)
"I'm sure the moon hoaxers would like to know whether or not it saw the American flag we left up there."
No, they would want to know that it didn't see the flag:
Moon Hoaxer: Did it see the flag?
Chinese Scientist: Well, it's not designed to see anything that small
Moon Hoaxer (interrupting): DID IT SEE THE FLAG, YES OR NO?
Chinese Scientist: No, but it wouldn't see
Moon Hoaxer (interrupting): SEE I TOLD YOU ALL IT WAS A HOAX HERE'S PROOF.
What they wouldn't want to know would be if it did see the flag:
Moon Hoaxer: Did it see the flag?
Chinese Scientist: Actually, yes, here's the flag, here's the lander
Moon Hoaxer (interrupting): FAKE! FAKE! YOU ARE JUST IN ON THE CONSPIRACY! FAKE!
"If this is supposed to supplant AMBE, why not AMBE2 or S(uper)AMBE?"
Because:
1) AMBE is trademarked by DVSI, Inc. You would be infringing upon that and be sued into oblivion.
2) This codec is not based on Multi-Band Excitation (IMBE - Improved Multi-Band Excitation. AMBE - Advanced Multi-Band Excitation). Naming it thus would be an error.
"But the Outsiders only went to We Made It because of a Puppeteer deployed starseed lure."
You beat me to it.
SO, the Puppeteers have hyperdrive, and so if they show up, open trading relations, so we don't have to wait for the Outsiders.
Offer to go to the galactic core, or do a close orbit around a neutron star in a GP3, or whatever, but get that hyperdrive.
(besides, who knows if they don't already have second quantum yet? Sure, they told Beowulf they just developed it, but for all we know they'd been sitting on it for centuries, too afraid to build it.).
I don't have the sample files, but the TIA test document I linked to in my previous post gives a lot of data on how they modeled the impairments - that might give you a start. If I happen to run across any of the samples (and can redistribute them) I'll let you know. You might also contact the TIA and see if you can get the WAV files from them.
As an interesting experiment, you might try reproducing a test I did on the IMBE vocoder used in APCO-25 Phase 1: take the first 10 seconds of Kansas's "Carry On Wayward Son" - the acapella vocal harmony - and run that through. IMBE went nuts on the signal - it sounded like you were listening through a fan. I think the closely related frequency components of the various voices were too much for it to handle.
It's called "asymptotic freedom".
In a QGP, for the time and distance scales in question (very short and very small), a quark can act as though it is free to move, like a dog on a rope in the yard - as long as it doesn't go very far, it can move freely without the rope (a string of gluons) yanking it around. Since the density of the QGP is very high, just being able to roam his yard is enough - there's plenty of things to chase/bark at/hump in his yard, he doesn't NEED to go beyond it, and his rope doesn't change his behavior.
However, as the QGP cools and expands, all the good stuff leaves the yard, and poor ol' DownBoy can't get at anything without running into the end of his rope.
So as long as all the neighborhood UpBitches, LeptonCats, W-kids, Z-leaves, and other things are squeezed into his yard, DownBoy has asymptotic freedom. Let things cool, and his gluon leash is cramping his style again.