Well, whatever you call it, the US wanted it, the US forced it on everybody, and the US shouldn't complain about it.
Other nations do indeed have cause to complain, like about the insane agricultural subsidies the US tax payer gives to US farmers, subsidies that are killing farmers in other nations.
Having a high quality national ID card, with or without biometrics, is a good thing: it lets you prove more reliably who you are when you choose to.
What's a bad thing is to make carrying and showing a national ID mandatory. What's also bad is storing the biometric identifiers or other new information contained on it in a national database (the other information on it is in numerous national databases already anyway).
The code treats I/O operations just like any other pointer update instead of defining an accessor for the hardware. It also seems to use Hungarian notation ("..._ptr").
A saner thing in both C and C++ is to write
io_set_SOMEREG(BIT_A|BIT_B);
In C, this can be a macro, in C++, an inline function. It doesn't cost you anything to do that in terms of performance, but it documents what is going on, it lets you trace and/or debug things, it makes it easier to port the code to new hardware, it lets you add debugging code and/or assertions, etc. Internally, "io_set_SOMEREG" can then be as gross as you like.
Furthermore, if the register really is a "uint16_t", like the C++ code indicates, there should be an explicit cast to that effect in the C code, because whatever compiler he may be using, an "int" is not going to be the same as a "unit16_t".
The comparison is also bogus because the guy didn't even show how he got SOMEREG_ptr, which is a pretty gross operation in C as well.
For the C++ code, using "typedef" and "using" would help with the notational problems the programmer seems to be having, as in
In fact, several languages force programmers to create typedefs for every template instantiation, presumably to avoid messes like this guy is creating.
But that's not the worst of it. Rather, he puts all the complexities of template classes into his code and still scatters offsets and hardware updates in places where they don't seem to belong. A better thing is to actually define an object that encapsulates the hardware:
class AirplaneHardware { public:
void enable_fuel_pump();
void disable_fuel_pump(); }
That's actually much closer to what a sane C programmer might have written historically: he might have defined a C structure representing the hardware register set and updated registers through that.
So, the C++ code would look like:
hardware.enable_fuel_pump();
And that is indeed better than
*SOMEREG_ptr = BIT_A|BIT_B;
Re:C++ in embedded applications is a bad idea
on
C++ In The Linux kernel
·
· Score: 0, Flamebait
Both your C and your C++ code absolutely suck. It's scary to think they let you anywhere near avionics of any type.
Neither are C programmers. But unlike C programmers, who keep making the same mistakes generation after generation, C++ compilers are actually getting better with time.
any compiler or language that likes to hide things like memory allocations behind your back just isn't a good choice for a kernel.
But C++ doesn't hide memory allocation behind anybody's back. You get to decide exactly where memory allocation happens and where it doesn't.
* you can write object-oriented code (useful for filesystems etc) in C, _without_ the crap that is C++.
Yes, because it is so much "better" to let every programmer make up their own crap rather than to have an efficient, compiler supported standard for dispatch tables.
The simple reason for that is that otherwise the kernel would be unpredictable.
Complex code becomes predictable by building layered abstractions with well-defined interfaces. C++ supports that better than C.
Let's say the error logging function used the string class (which likes to allocate memory behind your back).
The kernel almost certainly wouldn't be using "the" string class, but its own string class, adapted specifically to the needs of the kernel. Right now, the C-based kernel doesn't use the user mode C library either, after all.
If the memory allocation function fails and tries to print an error message... you got yourself a kernel crash.
Quite to the contrary. Not only would the kernel not crash, with a properly designed string class, out of memory conditions would actually be guaranteed to be handled correctly in all string operations everywhere in the kernel. No more case-by-case checking and handling of whether the memory allocation happened to succeed this time or not. In this particular case, the string class would throw an out-of-memory exception in the error handler and the stack would unwind up to the point where there is a handler.
Furthermore, the error logging function can decide to intercept such exceptions and print an emergency error message on the console, and it can do so reliably without ever having to worry about checking a single status or return value.
Altogether, this is a big improvement over C-based handling of such situations. But if you want to keep this situation from occurring in the first place, there is no more reason for the error logging function to allocate memory in C++ than there is for it to do so in C.
C++ could help a lot making kernel development faster, making it easier to use more efficient data structures, and making it easier to avoid resource leaks, buffer overflows, and other problems. Whether or not this leads to any inefficiencies or code bloat in the kernel is up to the kernel developers; C++ has many faults and it fails to fix many of C's problems, but it does deliver on its main promise: you pay only for what you use.
But in order to make C++ work in the kernel, the kernel developers need to stand behind it, set clear coding guidelines, and be committed to it. I don't see that yet.
Um...this is a POLITICAL CAMPAIGN SITE. The people not voting next week should have NO IMPACT here.
But the investors deciding where to invest their money this week, next week, and the week after, and every week after that have a HUGE IMPACT. And they look at US politics in great detail to decide whether their money would be safe in the US and whether they will likely get a good return on their investment.
I think most people outside the US would be elated to see such a degree of interest by Americans in any politics outside their borders. They probably suspect that most Americans couldn't even name the presidents of other major nations, let alone the opposition candidates.
A non-American's opinion in the 2004 presidential election is pretty much as irrelevant as it gets.
Quite to the contrary: what international investors believe about US politics is vitally important to the US. Should they lose confidence in the US, they'll pull out their money and the US economy will collapse.
You do realize that, fundamentally, no matter how "ironic" you think it is, that non-US citizens do not and should not have any say whatsoever in the outcome of US elections? And that, therefore, US political campaign sites have no actual reason to serve anyone other than voters?
Non-US citizens can't vote in the US, but they vote on their own government and they decide how to allocate their funds. Right now, the US is still able to borrow $500 billion every year because people still basically trust it. Part of that trust is transparency. People also still buy hundreds of billions of dollars of US exports every years.
Should the US political process start being perceived as non-transparent, all of that could come to a screeching halt: investors would pull out their money and the dollar would tumble. If the US really annoys people, US exports might suffer as well, no matter how cheap they may be.
The US is wealthy and powerful only because the rest of the world has a reasonable degree of confidence. And actions like Bush's threaten to undermine that.
America has a vital interest in presenting itself to the rest of the world openly, freely, and without the slightest hint of xenophobia or isolationism.
It was a GREAT experiment...we made up some of the money we would have lost, and was able to share data with our friends.
No, it wasn't because the outcome was completely predictable: you didn't market and package your product correctly and people perceived it as cheap and they pirated it. In different words, do you really need to hit your thumb with a hammer in order to figure out that it hurts?
The real story here is if you're a small business shipping some kind of media, it's going to get ripped. And people will rationalize the pirating any way they can.
Yes, that is the real story. And the smart business figures out how to thrive despite of it. You can do that by marketing and pricing your product correctly.
No, it assumes that you make a conscious choice of how to spend your time. Spending the time to get an old computer working is time spent usefully: it helps the environment and it helps yourself because you learn something. If you go the route of shopping for the latest PC, you have to spend many hours working to earn the money, then spend time buying it, and then still deal with lots of software issues (patches, installation, etc.).
You inevitably spend each hour on something. The question is on what.
The same goes for software - Linux is great for futzing around, but I'd rather work for a few hours and buy software that *just works*,
Linux just works. It's Windows that requires endless futzing around.
Sheesh, that's why I work: to be able to afford good-quality tools that will save me time.
So why the hell do you buy Windows machines for your personal use then?
Re:Sacrifice hardware for the good of software?
on
How Cheap Can A PC Be?
·
· Score: 0, Troll
But people *STILL* couldn't understand why a few dozen bytes of added data to each patch caused the stuff to double the price. The fact was, it took at least twice as long to convert this stuff and the man power cost more than the equipment to record in the first place.
Well, so your and Kurzweil's business model, packaging, and marketing was poorly thought out. Perhaps Kurzweil should have defined a ROM standard for samples, or a Smartcard standard. Don't blame others for his lack of business skills or your bad choice of platform.
No matter what you sell for, it will always be too much for someone.
Yes, and any reasonably smart business person knows how to use that fact to their advantage, rather than whining about it.
The fact of the matter is, if you price something lower, you are not going to increase your sales.
The fact of the matter is, that depends entirely on what the something is, how you market it, and how much other people are charging for something comparable.
"Fair"? In what sense is getting a cheap price only because you illegally obtain a copy of MS Office by fraudulently misrepresenting yourself as a "student" (as the parent post suggested) "fair"? In what sense is getting students hooked on proprietary document formats and user interfaces early on in their careers so that they later will by the full-priced package when they grow up to be corporate drones "fair"?
The Linksys machine runs Linux: you turn it on and it works. If you want to use it interactively, search for "linksys linux" on Google and it tells you how to install Linux on it. SourceForge even has a version of Linux that loads into RAM (no change to Flash).
However, as a PC, you really need a VGA output and a USB connector for a keyboard--cheap additions, but they aren't there on this particular model. So, it's more of an existence proof than a usable system. But an existence proof it is.
It s important to note that the license is only relevant to those organizations (ISP, large enterprises)who will be checking e-mails using the PRA check alternative of the Sender ID Framework need to secure a license.
Think about the consequences of that. Even if Microsoft follows through on its promise to make the license available "for free" to anybody, it means that if you buy a Microsoft mailer or a mailer from a sublicensee, you can just install it and run it. If you install an "open source" mailer, however, your legal department needs to execute a licensing agreement with Microsoft's legal department. The costs and delays resulting from that alone make the "open source" mailer uncompetitive, no matter how much better it may be than Microsoft's products.
That is why the official open source definition does not allow such patents: if software implements such a patented invention and requires a licensing agreement with Microsoft, that software simply is not "open source", even if it it is distributed under the text of an open source license--the existence of the patent and licensing requirement makes it not open source.
You can get a Linksys wireless router for about $70. It's a machine with 16M of memory, 4M of flash, and a 125 or 200MHz chip. It also comes with a hub, a wired Ethernet, WiFi, and a power supply. So, that shows you can ship a lot of hardware for fairly little money.
Replace WiFi with a simple VGA controller and give it a couple of USB ports and a little more flash instead of the hub and you would end up, at roughly the same price, with a usable personal computer that could run a light X11 desktop and some useful apps (browser, word processor, etc.). If you add a CF slot, people even have removable storage.
Another choice is the standalone file server appliance, also for under $100 AFAIK; it already has the USB port and also runs Linux.
And some of the game consoles also show it can be done, if you get the volume high enough.
By a "flaky language", I don't mean that there are problems with the implementations or portability (which there may be as well). Rather, I mean that the language contains convenience features that may seem nice when writing smaller pieces of software but that can cause headaches when debugging large, multi-developer projects. Things like the fact that "+" will happily revert to string concatenation when trying to add a number and a string, or the fact that instance variables just get created automagically.
Yes, this will happen. The limits are size, weight, cost, storage, and battery life. At an acceptable cost, you can already get something that is small, light, and cheap. Storage is still too expensive for continuous recording. But the hardest obstacle to overcome is battery life. Either the electronics get a whole lot more energy efficient still (maybe we can even run these things off small solar cells then, like simple calculators), or batteries have to get a whole lot better.
Oh, and if you want wireless transmission, that's still going to cost you because wireless providers still want to milk the cash cow a little longer.
Slashdot Mirror
Well, whatever you call it, the US wanted it, the US forced it on everybody, and the US shouldn't complain about it.
Other nations do indeed have cause to complain, like about the insane agricultural subsidies the US tax payer gives to US farmers, subsidies that are killing farmers in other nations.
Having a high quality national ID card, with or without biometrics, is a good thing: it lets you prove more reliably who you are when you choose to.
What's a bad thing is to make carrying and showing a national ID mandatory. What's also bad is storing the biometric identifiers or other new information contained on it in a national database (the other information on it is in numerous national databases already anyway).
but we have to assure our more senior executives that these boxes have the same level of security and protection as the commercial products
If Linux had the same level of security and protection as the commercial products, I wouldn't want to be using it.
A saner thing in both C and C++ is to writeIn C, this can be a macro, in C++, an inline function. It doesn't cost you anything to do that in terms of performance, but it documents what is going on, it lets you trace and/or debug things, it makes it easier to port the code to new hardware, it lets you add debugging code and/or assertions, etc. Internally, "io_set_SOMEREG" can then be as gross as you like.
Furthermore, if the register really is a "uint16_t", like the C++ code indicates, there should be an explicit cast to that effect in the C code, because whatever compiler he may be using, an "int" is not going to be the same as a "unit16_t".
The comparison is also bogus because the guy didn't even show how he got SOMEREG_ptr, which is a pretty gross operation in C as well.
For the C++ code, using "typedef" and "using" would help with the notational problems the programmer seems to be having, as inIn fact, several languages force programmers to create typedefs for every template instantiation, presumably to avoid messes like this guy is creating.
But that's not the worst of it. Rather, he puts all the complexities of template classes into his code and still scatters offsets and hardware updates in places where they don't seem to belong. A better thing is to actually define an object that encapsulates the hardware:That's actually much closer to what a sane C programmer might have written historically: he might have defined a C structure representing the hardware register set and updated registers through that.
So, the C++ code would look like:And that is indeed better than
Both your C and your C++ code absolutely suck. It's scary to think they let you anywhere near avionics of any type.
The fact is, C++ compilers are not trustworthy.
Neither are C programmers. But unlike C programmers, who keep making the same mistakes generation after generation, C++ compilers are actually getting better with time.
any compiler or language that likes to hide things like memory allocations behind your back just isn't a good choice for a kernel.
But C++ doesn't hide memory allocation behind anybody's back. You get to decide exactly where memory allocation happens and where it doesn't.
* you can write object-oriented code (useful for filesystems etc) in C, _without_ the crap that is C++.
Yes, because it is so much "better" to let every programmer make up their own crap rather than to have an efficient, compiler supported standard for dispatch tables.
The simple reason for that is that otherwise the kernel would be unpredictable.
Complex code becomes predictable by building layered abstractions with well-defined interfaces. C++ supports that better than C.
Let's say the error logging function used the string class (which likes to allocate memory behind your back).
The kernel almost certainly wouldn't be using "the" string class, but its own string class, adapted specifically to the needs of the kernel. Right now, the C-based kernel doesn't use the user mode C library either, after all.
If the memory allocation function fails and tries to print an error message... you got yourself a kernel crash.
Quite to the contrary. Not only would the kernel not crash, with a properly designed string class, out of memory conditions would actually be guaranteed to be handled correctly in all string operations everywhere in the kernel. No more case-by-case checking and handling of whether the memory allocation happened to succeed this time or not. In this particular case, the string class would throw an out-of-memory exception in the error handler and the stack would unwind up to the point where there is a handler.
Furthermore, the error logging function can decide to intercept such exceptions and print an emergency error message on the console, and it can do so reliably without ever having to worry about checking a single status or return value.
Altogether, this is a big improvement over C-based handling of such situations. But if you want to keep this situation from occurring in the first place, there is no more reason for the error logging function to allocate memory in C++ than there is for it to do so in C.
C++ could help a lot making kernel development faster, making it easier to use more efficient data structures, and making it easier to avoid resource leaks, buffer overflows, and other problems. Whether or not this leads to any inefficiencies or code bloat in the kernel is up to the kernel developers; C++ has many faults and it fails to fix many of C's problems, but it does deliver on its main promise: you pay only for what you use.
But in order to make C++ work in the kernel, the kernel developers need to stand behind it, set clear coding guidelines, and be committed to it. I don't see that yet.
Um...this is a POLITICAL CAMPAIGN SITE. The people not voting next week should have NO IMPACT here.
But the investors deciding where to invest their money this week, next week, and the week after, and every week after that have a HUGE IMPACT. And they look at US politics in great detail to decide whether their money would be safe in the US and whether they will likely get a good return on their investment.
I think most people outside the US would be elated to see such a degree of interest by Americans in any politics outside their borders. They probably suspect that most Americans couldn't even name the presidents of other major nations, let alone the opposition candidates.
A non-American's opinion in the 2004 presidential election is pretty much as irrelevant as it gets.
Quite to the contrary: what international investors believe about US politics is vitally important to the US. Should they lose confidence in the US, they'll pull out their money and the US economy will collapse.
You do realize that, fundamentally, no matter how "ironic" you think it is, that non-US citizens do not and should not have any say whatsoever in the outcome of US elections? And that, therefore, US political campaign sites have no actual reason to serve anyone other than voters?
Non-US citizens can't vote in the US, but they vote on their own government and they decide how to allocate their funds. Right now, the US is still able to borrow $500 billion every year because people still basically trust it. Part of that trust is transparency. People also still buy hundreds of billions of dollars of US exports every years.
Should the US political process start being perceived as non-transparent, all of that could come to a screeching halt: investors would pull out their money and the dollar would tumble. If the US really annoys people, US exports might suffer as well, no matter how cheap they may be.
The US is wealthy and powerful only because the rest of the world has a reasonable degree of confidence. And actions like Bush's threaten to undermine that.
America has a vital interest in presenting itself to the rest of the world openly, freely, and without the slightest hint of xenophobia or isolationism.
Is it compatible with gcj and other free Java-like platforms, or does it require Sun's proprietary Java implementation?
It was a GREAT experiment...we made up some of the money we would have lost, and was able to share data with our friends.
No, it wasn't because the outcome was completely predictable: you didn't market and package your product correctly and people perceived it as cheap and they pirated it. In different words, do you really need to hit your thumb with a hammer in order to figure out that it hurts?
The real story here is if you're a small business shipping some kind of media, it's going to get ripped. And people will rationalize the pirating any way they can.
Yes, that is the real story. And the smart business figures out how to thrive despite of it. You can do that by marketing and pricing your product correctly.
No, it assumes that you make a conscious choice of how to spend your time. Spending the time to get an old computer working is time spent usefully: it helps the environment and it helps yourself because you learn something. If you go the route of shopping for the latest PC, you have to spend many hours working to earn the money, then spend time buying it, and then still deal with lots of software issues (patches, installation, etc.).
You inevitably spend each hour on something. The question is on what.
The same goes for software - Linux is great for futzing around, but I'd rather work for a few hours and buy software that *just works*,
Linux just works. It's Windows that requires endless futzing around.
Sheesh, that's why I work: to be able to afford good-quality tools that will save me time.
So why the hell do you buy Windows machines for your personal use then?
But people *STILL* couldn't understand why a few dozen bytes of added data to each patch caused the stuff to double the price. The fact was, it took at least twice as long to convert this stuff and the man power cost more than the equipment to record in the first place.
Well, so your and Kurzweil's business model, packaging, and marketing was poorly thought out. Perhaps Kurzweil should have defined a ROM standard for samples, or a Smartcard standard. Don't blame others for his lack of business skills or your bad choice of platform.
No matter what you sell for, it will always be too much for someone.
Yes, and any reasonably smart business person knows how to use that fact to their advantage, rather than whining about it.
The fact of the matter is, if you price something lower, you are not going to increase your sales.
The fact of the matter is, that depends entirely on what the something is, how you market it, and how much other people are charging for something comparable.
"Fair"? In what sense is getting a cheap price only because you illegally obtain a copy of MS Office by fraudulently misrepresenting yourself as a "student" (as the parent post suggested) "fair"? In what sense is getting students hooked on proprietary document formats and user interfaces early on in their careers so that they later will by the full-priced package when they grow up to be corporate drones "fair"?
The Linksys machine runs Linux: you turn it on and it works. If you want to use it interactively, search for "linksys linux" on Google and it tells you how to install Linux on it. SourceForge even has a version of Linux that loads into RAM (no change to Flash).
However, as a PC, you really need a VGA output and a USB connector for a keyboard--cheap additions, but they aren't there on this particular model. So, it's more of an existence proof than a usable system. But an existence proof it is.
I assume the chip in the router isn't the same as a cpu for desktops, but someone else can respond to that.
It's an ARM chip. It runs a Linux desktop just fine. It would presumably run a WinCE system as well.
The consoles are sold below-cost (many), and make up for it on licensing fees.
PS2 isn't. Xbox may or may not be. I don't know about the others.
Think about the consequences of that. Even if Microsoft follows through on its promise to make the license available "for free" to anybody, it means that if you buy a Microsoft mailer or a mailer from a sublicensee, you can just install it and run it. If you install an "open source" mailer, however, your legal department needs to execute a licensing agreement with Microsoft's legal department. The costs and delays resulting from that alone make the "open source" mailer uncompetitive, no matter how much better it may be than Microsoft's products.
That is why the official open source definition does not allow such patents: if software implements such a patented invention and requires a licensing agreement with Microsoft, that software simply is not "open source", even if it it is distributed under the text of an open source license--the existence of the patent and licensing requirement makes it not open source.
You can get a Linksys wireless router for about $70. It's a machine with 16M of memory, 4M of flash, and a 125 or 200MHz chip. It also comes with a hub, a wired Ethernet, WiFi, and a power supply. So, that shows you can ship a lot of hardware for fairly little money.
Replace WiFi with a simple VGA controller and give it a couple of USB ports and a little more flash instead of the hub and you would end up, at roughly the same price, with a usable personal computer that could run a light X11 desktop and some useful apps (browser, word processor, etc.). If you add a CF slot, people even have removable storage.
Another choice is the standalone file server appliance, also for under $100 AFAIK; it already has the USB port and also runs Linux.
And some of the game consoles also show it can be done, if you get the volume high enough.
By a "flaky language", I don't mean that there are problems with the implementations or portability (which there may be as well). Rather, I mean that the language contains convenience features that may seem nice when writing smaller pieces of software but that can cause headaches when debugging large, multi-developer projects. Things like the fact that "+" will happily revert to string concatenation when trying to add a number and a string, or the fact that instance variables just get created automagically.
Yes, this will happen. The limits are size, weight, cost, storage, and battery life. At an acceptable cost, you can already get something that is small, light, and cheap. Storage is still too expensive for continuous recording. But the hardest obstacle to overcome is battery life. Either the electronics get a whole lot more energy efficient still (maybe we can even run these things off small solar cells then, like simple calculators), or batteries have to get a whole lot better.
Oh, and if you want wireless transmission, that's still going to cost you because wireless providers still want to milk the cash cow a little longer.