Actually, it would have been funnier if I had proofread it and found that it's missing the word "have" (or "do") in between "doesn't" and "Blast". That's what happens when you do copy-and-paste editing. In my post I wasn't referring to the games the parent was talking about, I was simply riding his early, well-moderated comment to tack my joke on. If fact, I was not even aware those were Saturn games, since I've yet to meet someone who admits to having owned one of those machines.
If the people who run Slashdot had any brains, they'd have had a real Technology Jobs section, not a halfassed partnership with Hotjobs. I mean, they're running the biggest geek site on the planet, where many of these people spend their down time. If they had posted a real job section, they could take over that market (particularly in the OSS section). Imagine a site where people can post comments about the jobs listed, and potentially communicate that way with the employer for all to read (hey, there's something that other job sites just don't do), where I can specify that I want a job doing C but not C++ (no other site has the geek focus that you can find here), and where, if I'm looking for a job, I can have job results come up in between my other Slashdot stories (that I read every day anyway).
And employers would *pay* to post jobs. Imagine having your position seen by all system admins worldwide that checked a box that they want to see sysadmin jobs on their Slashdot homepage? The response would be huge. Of course, far be it from OSTG from doing something that could make them money.
You want a Linux desktop/server distribution that will hold your hand and install all the tools for you for embedded software development? It doesn't exist. At this level of work, you should be familiar enough with your tools to install and maintain them yourself. You'll need to know this stuff anyway when you find out that this object file compiled with gcc 2.95 doesn't work with the gcc 3.4 you installed.
There are two situations here. One is where you just need a development environment and cross compilers. In this situation, it makes no difference which distribution you use. Use the one you're most comfortable with. I've been working off of a 4 year old Redhat machine for all of my work, and just switched to a brand new Suse box, and I can't tell the difference. Hell, sometimes I use my MIPS cross compiler on Windows with Cygwin.
The second situation is one where you will be trying your software out the dev machine before you have target hardware. In this case, you'll want one whos kernel and the rest of the environment matches what you'll have on your target. You should be putting this Linux system together from scratch. Download a kernel (try the ARM ones), busybox and uclibc. VMWare is also your friend.
It's unbearably painful, if not impossible, to install Flash on a pure AMD64 Linux system (that is, exclusively 64-bit apps and libraries.)
I've got a present for you: A Firefox build that will work with Flash and Java on an AMD64 system. Download Swiftfox, the one compiled for Athlon 64. It says the compile is 32-bit, but it runs well on my pure AMD64 Ubuntu 6.06 system (with no chroot environment). Then go to a site with flash, and allow it to install the flash player.
A couple of caveats: 1) The flash plugin will crash the native Firefox if it tries to use it. It's installed somewhere in your home directory, you should delete it if you're going back to FF. 2) You can't run FF and Swiftfox at the same time. You must close all windows of one before opening the other.
I sure hope this happens; then I can finally switch back to 64-bit mode
I sure hope this happens, so that I can finally have Macromedia Flash player and WMV decoding working on my AMD64 system. Two things I thought I'd never miss, but am finding it a pain to live without.
Not so easily. It is unlikely that they will give you block-level access to the drive. That is, you can't format it. However, there is a solution. You just fill the drive with one huge file that contains a virtual disk image, and now you can format that with anything you want, and raid it with other disk images on other servers.
As a bonus, you get disk encryption essentially for free. Here is a great app for Windows and Linux for creating and mounting encrypted drives in a file that I've used to do exactly this (on SMB servers). For those of you using XP, here is a guide on how to hack XP to enable the raid5 features that are disabled in the non-server versions.
As an Ubuntu user and fan, I'd just like to say: for fuck's sake, stop it with the stupid names! Breezy Badger, Dapper Drake, Edgy Eft. Seriously, I feel like a jackass enough saying "Ubuntu". I don't understand, are they actively trying to discourage people from using it?
so if(status = 1) in his code is always true. In your code, not neccesarily. Hence, his is a bug. And funny.
Look again. This time, look for any extra semi-colons that shouldn't be there. The responder's joke was an improvement on the original, and would not have been flagged by an optional compiler warning (at least in the case of gcc).
Sun was always hoping, and still is, that others will take the SPARC design and implement their own chips. They want economies of scale to start playing into SPARC like it has into the x86 and ARM market. Obviously, joe hacker is not going to be doing this, but there are some companies that can and very well might.
Here's why other people would want to make SPARC chips: Linux. Oh no, here comes the zealot talk. Actually, not quite. Linux runs on the three leading server architectures, x86 (+AMD64), POWER, and SPARC. From a deployment and administration standpoint, you don't really care what CPU you're running on. With the T1, Sun released the CPU with the highest performance per Watt on the market (for some tasks). This is an attractive chip, but buying from Sun is not always appealing. Sun gear is pretty expensive.
Today, there are many Taiwanese and Chinese motherboard makers, and they sell lots and lots of hardware. But their chips must always come from Intel or AMD (or Via, who's never been competitive). They would love nothing more than to have a standard CPU architecture that they can manufacture (TSMC or PMC can fab these for them) and take the profit cut from instead of handing that business to Intel. With Sun's release, they now have the tools to make a chip that is not only competitive with x86 and Power, but is actually top of the line, and at no additional cost to them. It already runs Linux, it's ready for blades, they know it will sell.
Sun benefits by having cheaper SPARC CPUs on the market, driving down their costs and increasing their architecture share. The manufacturers benefit by being able to sell at the high end, and sell cheaper. Server buyers benefit, because there is now a cheap source for high end machines. Now, if these chips really move, don't be surprised to see Texas Instruments (who doesn't have a server chip, but does have the fabs and experience with SPARC) and even IBM (who will make whatever sells) start to make these.
Malloc() is written for generic memory allocation for all programs with no bias towards larger sizes (or smaller) or allowing fragmentation rates which in the past would've been a kill-all for most applications.
This is misleading. The malloc() interface has no bias, but the implementation is designed to make both small and fast allocations quick. In fact, you'll see that for large allocations, glibc malloc() uses mmap() to allocate memory (as you seem to advocate in a followup post), while making page requests for smaller chunks. It also maintains separate lists for small and large chunks, and is able to assign very small chunks in their own area to minimize fragmentation, excess allocation, and lookup times for best fit.
Sure, except that as soon as your "driver-bootstrapping driver" gets populer, Microsoft will have your signing certification revoked (since it probably violates their license), and your driver will no longer work.
This is the worst advice ever posted on Slashdot. Congratulations. The scary part is that it got modded "Insightful".
Checking malloc in the middle of your code is essentially an obsolete practice for real-world systems -- it's essentially impossible to cleanly back out of all failures, and nobody is going to test all possible failure conditions. The fact that Linux uses an OOM killer and overcommits by default is just a recognition of this fact.
It is not impossible to cleanly back out failure states. It is difficult. Don't confuse the two. Your job as a programmer is not to make your life easy, it's to write programs that function correctly. Handling memory errors correctly (say, not losing the user's states and corrupting their current working file due to allocation error) is part of the program's role. Advice like this leads to the type of apps that die mysteriously for no apparent reason, leaving no trace or debug message of what went wrong.
* Do you actually test each bit of cleanup and error-recovery code? I mean, are you using a malloc()/free() wrapper that causes *every* path to be invoked? Otherwise, you're just bloating your application with masses of untested code.
No. I test most. I have good confidence in my coding skills for the rest. Yes, there are bugs, that is inevitable. But handling most error cases correctly (obviously I try for total coverage) is better than handling none of them.
* Are you certain that you can't run out of stack space, not just heap space? Particularly if you're using C++ and local objects, I'm pretty dubious that you're so sure. Do you really know, for certain, how much space a random STL object uses?
Well, in my embedded systems, I do. On more conventional machines, not really. But I do know that any well written code will not allocate excessively-large objects on the stack and avoid recursion. My code will never use more than a few kilobytes of stack space (or hundreds, in embedded situaitons), and if that much is not availabe, the program never had a chance of working correctly.
Systems these days have so much memory and virtual memory that running out of memory is almost *always* a bug. It's a pretty safe bet that the allocation that causes your app to run out of memory is the culprit. Even if Linux didn't have an OOM killer, I'd feel safe in almost all circumstances just wrapping malloc() with an abort() on failure.
This is an incorrect assertion and a terrible programming practice. Imaging your Linux box is running 1000 processes, 1 sshd and 999 apache instances. If traffic spikes up, and the apaches start consuming more memory, the system may not have enough to give them, and they may gracefully handle it. But if sshd was coded using your standards, it would crash if someone tried to initiate a connection because it did not check its malloc return. I think we can all agree that under no circumstances should increased memory use by apache (not a bug) cause sshd to crash.
Some applications might be fed huge workloads inadvertently. Those are better off adding checks specifically for those workloads. For example, if you load a huge image in the GIMP, you'll get a warning based on the size before the GIMP attempts to do memory allocation, not after the failure happens.
And how exactly does the GIMP know how much memory is available to it at any time? It may be running on a box with 16 megs of RAM, or 16 gigs. The system may have memory allocated to other things right now that was available five seconds ago. I'd like to see portable code that can predict when nontrivial resource allocation will fail.
All in all, this kind of programming leads to the worst kind of software. Code with no regard for memory utilization. Code that does not know if realloc worked and goes on silently corrupting memory until it fails later down the line. Code that leads to memory leaks, buffer overflows, and denial of service attacks due to its disregard for error conditions. I hope that I shall never encounter your code in my lifetime.
Or maybe they won't realize it, and you'll be writing the kind of code that ends up on The Daily WTF. The reality is, unqualified graduates have been coming out of CS programs for years. The problem is that many employers have no good way to guage whether a candidate can really write code or not. In the mean time, you can take comfort that these incompetent employees will be moved the where they can do the least damage, management (The Dilbert Principle)
Did you make this account especially for me? I'm touched.
Honestly, the CCS issues are not my primary concerns with TI. All other things being on par with other firms, I could live with it (though I'd be cursing TI daily), and I imagine it's improved somewhat since we started with it. But I've seen too many projects burned by poor Texas Instruments support to ever think of trying it again.
I remember going to a DSC124(?) training class some years back (back when the chip was new). The instructor could not even give me a copy of the example code we did in class, because, god forbid, I would want to make your chip work when I got back to my office (I'm talking about something on the order of code showing how to use the MAC on this part, not any real software).
Thank you for your suggestions about writing TI support. It's been two years since my company followed through on my recommendation to abandon our last TI part (not including DACs), so I'm grateful to say that I require no more support from your company. After years of having email and phone calls ignored, playing shuffle-the-FAE, being pawned off on third parties, and being told outright that software designed to operate some part or feature is unsupported and yet documents for that same part are unavailable, I have no interest in seeing TI improve. Your issues are political, not technological, and I have no confidence that there is interest in resolving these. I will pursue a different strategy: I will deal with your competitors. What they lack in hardware design skill, they make up in support. TI's anemic support response is a greater risk to a project I undertake than any silicon bug.
Interesting theory. However, we didn't pay for hardware with it, and have had no problem running the software with no hardware attached or with new hardware we've made (and different JTAG devices). I don't remember what the emulator was, but thankfully I never have to look at it again.
Slashdot Mirror
you should really be using tar(1) for that.
Actually, it would have been funnier if I had proofread it and found that it's missing the word "have" (or "do") in between "doesn't" and "Blast". That's what happens when you do copy-and-paste editing. In my post I wasn't referring to the games the parent was talking about, I was simply riding his early, well-moderated comment to tack my joke on. If fact, I was not even aware those were Saturn games, since I've yet to meet someone who admits to having owned one of those machines.
The PSP doesn't Blast Processing (tm), so I don't see how any of these games are going to work.
A Mac without Win32 is like a chocolate cake without ketchup and mustard. Thanks, TransGaming, for remembering to bring the condiments.
If the people who run Slashdot had any brains, they'd have had a real Technology Jobs section, not a halfassed partnership with Hotjobs. I mean, they're running the biggest geek site on the planet, where many of these people spend their down time. If they had posted a real job section, they could take over that market (particularly in the OSS section). Imagine a site where people can post comments about the jobs listed, and potentially communicate that way with the employer for all to read (hey, there's something that other job sites just don't do), where I can specify that I want a job doing C but not C++ (no other site has the geek focus that you can find here), and where, if I'm looking for a job, I can have job results come up in between my other Slashdot stories (that I read every day anyway).
And employers would *pay* to post jobs. Imagine having your position seen by all system admins worldwide that checked a box that they want to see sysadmin jobs on their Slashdot homepage? The response would be huge. Of course, far be it from OSTG from doing something that could make them money.
You want a Linux desktop/server distribution that will hold your hand and install all the tools for you for embedded software development? It doesn't exist. At this level of work, you should be familiar enough with your tools to install and maintain them yourself. You'll need to know this stuff anyway when you find out that this object file compiled with gcc 2.95 doesn't work with the gcc 3.4 you installed.
There are two situations here. One is where you just need a development environment and cross compilers. In this situation, it makes no difference which distribution you use. Use the one you're most comfortable with. I've been working off of a 4 year old Redhat machine for all of my work, and just switched to a brand new Suse box, and I can't tell the difference. Hell, sometimes I use my MIPS cross compiler on Windows with Cygwin.
The second situation is one where you will be trying your software out the dev machine before you have target hardware. In this case, you'll want one whos kernel and the rest of the environment matches what you'll have on your target. You should be putting this Linux system together from scratch. Download a kernel (try the ARM ones), busybox and uclibc. VMWare is also your friend.
It's unbearably painful, if not impossible, to install Flash on a pure AMD64 Linux system (that is, exclusively 64-bit apps and libraries.)
I've got a present for you: A Firefox build that will work with Flash and Java on an AMD64 system. Download Swiftfox, the one compiled for Athlon 64. It says the compile is 32-bit, but it runs well on my pure AMD64 Ubuntu 6.06 system (with no chroot environment). Then go to a site with flash, and allow it to install the flash player.
A couple of caveats:
1) The flash plugin will crash the native Firefox if it tries to use it. It's installed somewhere in your home directory, you should delete it if you're going back to FF.
2) You can't run FF and Swiftfox at the same time. You must close all windows of one before opening the other.
Have fun.
Ahem:
Those who do not understand Unix are condemned to reinvent it, poorly.
I sure hope this happens; then I can finally switch back to 64-bit mode
I sure hope this happens, so that I can finally have Macromedia Flash player and WMV decoding working on my AMD64 system. Two things I thought I'd never miss, but am finding it a pain to live without.
Thank you. I've read more than 30 high-modded posts in this article, and yours is the best explanation of the issue by far.
Not so easily. It is unlikely that they will give you block-level access to the drive. That is, you can't format it. However, there is a solution. You just fill the drive with one huge file that contains a virtual disk image, and now you can format that with anything you want, and raid it with other disk images on other servers.
As a bonus, you get disk encryption essentially for free. Here is a great app for Windows and Linux for creating and mounting encrypted drives in a file that I've used to do exactly this (on SMB servers). For those of you using XP, here is a guide on how to hack XP to enable the raid5 features that are disabled in the non-server versions.
As an Ubuntu user and fan, I'd just like to say: for fuck's sake, stop it with the stupid names! Breezy Badger, Dapper Drake, Edgy Eft. Seriously, I feel like a jackass enough saying "Ubuntu". I don't understand, are they actively trying to discourage people from using it?
I am not sure about this, but I think Al Gore did invent Internet.
That's a common misconception. Al Gore is actually the inventor of the Algorithm. The Internet was invented by AOL.
so if(status = 1) in his code is always true. In your code, not neccesarily. Hence, his is a bug. And funny.
Look again. This time, look for any extra semi-colons that shouldn't be there. The responder's joke was an improvement on the original, and would not have been flagged by an optional compiler warning (at least in the case of gcc).
if(status == 1);
Sun was always hoping, and still is, that others will take the SPARC design and implement their own chips. They want economies of scale to start playing into SPARC like it has into the x86 and ARM market. Obviously, joe hacker is not going to be doing this, but there are some companies that can and very well might.
Here's why other people would want to make SPARC chips: Linux. Oh no, here comes the zealot talk. Actually, not quite. Linux runs on the three leading server architectures, x86 (+AMD64), POWER, and SPARC. From a deployment and administration standpoint, you don't really care what CPU you're running on. With the T1, Sun released the CPU with the highest performance per Watt on the market (for some tasks). This is an attractive chip, but buying from Sun is not always appealing. Sun gear is pretty expensive.
Today, there are many Taiwanese and Chinese motherboard makers, and they sell lots and lots of hardware. But their chips must always come from Intel or AMD (or Via, who's never been competitive). They would love nothing more than to have a standard CPU architecture that they can manufacture (TSMC or PMC can fab these for them) and take the profit cut from instead of handing that business to Intel. With Sun's release, they now have the tools to make a chip that is not only competitive with x86 and Power, but is actually top of the line, and at no additional cost to them. It already runs Linux, it's ready for blades, they know it will sell.
Sun benefits by having cheaper SPARC CPUs on the market, driving down their costs and increasing their architecture share. The manufacturers benefit by being able to sell at the high end, and sell cheaper. Server buyers benefit, because there is now a cheap source for high end machines. Now, if these chips really move, don't be surprised to see Texas Instruments (who doesn't have a server chip, but does have the fabs and experience with SPARC) and even IBM (who will make whatever sells) start to make these.
Malloc() is written for generic memory allocation for all programs with no bias towards larger sizes (or smaller) or allowing fragmentation rates which in the past would've been a kill-all for most applications.
This is misleading. The malloc() interface has no bias, but the implementation is designed to make both small and fast allocations quick. In fact, you'll see that for large allocations, glibc malloc() uses mmap() to allocate memory (as you seem to advocate in a followup post), while making page requests for smaller chunks. It also maintains separate lists for small and large chunks, and is able to assign very small chunks in their own area to minimize fragmentation, excess allocation, and lookup times for best fit.
Dude, the Ides of March is, like, so yesterday
The Ides of March was today when I submitted this story, which was yesterday (about 5 PM Pacific).
Wait until you see what happens with the water generated by these things...
Headline: Fuel Cells for Laptops Due Next Week
Subtitle: Embarrased-looking early adopters with warm wet spots in their laps due week after that
Sure, except that as soon as your "driver-bootstrapping driver" gets populer, Microsoft will have your signing certification revoked (since it probably violates their license), and your driver will no longer work.
This is the worst advice ever posted on Slashdot. Congratulations. The scary part is that it got modded "Insightful".
Checking malloc in the middle of your code is essentially an obsolete practice for real-world systems -- it's essentially impossible to cleanly back out of all failures, and nobody is going to test all possible failure conditions. The fact that Linux uses an OOM killer and overcommits by default is just a recognition of this fact.
It is not impossible to cleanly back out failure states. It is difficult. Don't confuse the two. Your job as a programmer is not to make your life easy, it's to write programs that function correctly. Handling memory errors correctly (say, not losing the user's states and corrupting their current working file due to allocation error) is part of the program's role. Advice like this leads to the type of apps that die mysteriously for no apparent reason, leaving no trace or debug message of what went wrong.
* Do you actually test each bit of cleanup and error-recovery code? I mean, are you using a malloc()/free() wrapper that causes *every* path to be invoked? Otherwise, you're just bloating your application with masses of untested code.
No. I test most. I have good confidence in my coding skills for the rest. Yes, there are bugs, that is inevitable. But handling most error cases correctly (obviously I try for total coverage) is better than handling none of them.
* Are you certain that you can't run out of stack space, not just heap space? Particularly if you're using C++ and local objects, I'm pretty dubious that you're so sure. Do you really know, for certain, how much space a random STL object uses?
Well, in my embedded systems, I do. On more conventional machines, not really. But I do know that any well written code will not allocate excessively-large objects on the stack and avoid recursion. My code will never use more than a few kilobytes of stack space (or hundreds, in embedded situaitons), and if that much is not availabe, the program never had a chance of working correctly.
Systems these days have so much memory and virtual memory that running out of memory is almost *always* a bug. It's a pretty safe bet that the allocation that causes your app to run out of memory is the culprit. Even if Linux didn't have an OOM killer, I'd feel safe in almost all circumstances just wrapping malloc() with an abort() on failure.
This is an incorrect assertion and a terrible programming practice. Imaging your Linux box is running 1000 processes, 1 sshd and 999 apache instances. If traffic spikes up, and the apaches start consuming more memory, the system may not have enough to give them, and they may gracefully handle it. But if sshd was coded using your standards, it would crash if someone tried to initiate a connection because it did not check its malloc return. I think we can all agree that under no circumstances should increased memory use by apache (not a bug) cause sshd to crash.
Some applications might be fed huge workloads inadvertently. Those are better off adding checks specifically for those workloads. For example, if you load a huge image in the GIMP, you'll get a warning based on the size before the GIMP attempts to do memory allocation, not after the failure happens.
And how exactly does the GIMP know how much memory is available to it at any time? It may be running on a box with 16 megs of RAM, or 16 gigs. The system may have memory allocated to other things right now that was available five seconds ago. I'd like to see portable code that can predict when nontrivial resource allocation will fail.
All in all, this kind of programming leads to the worst kind of software. Code with no regard for memory utilization. Code that does not know if realloc worked and goes on silently corrupting memory until it fails later down the line. Code that leads to memory leaks, buffer overflows, and denial of service attacks due to its disregard for error conditions. I hope that I shall never encounter your code in my lifetime.
--
Any (nontrivial) program will be buggy.
Or maybe they won't realize it, and you'll be writing the kind of code that ends up on The Daily WTF. The reality is, unqualified graduates have been coming out of CS programs for years. The problem is that many employers have no good way to guage whether a candidate can really write code or not. In the mean time, you can take comfort that these incompetent employees will be moved the where they can do the least damage, management (The Dilbert Principle)
Stupid Flanders, always censoring the Internet.
Grammer tip: 'Effect' is used as a noun. 'Affect' is used as a verb.
Spelling tip: The word grammar has no E.
Did you make this account especially for me? I'm touched.
Honestly, the CCS issues are not my primary concerns with TI. All other things being on par with other firms, I could live with it (though I'd be cursing TI daily), and I imagine it's improved somewhat since we started with it. But I've seen too many projects burned by poor Texas Instruments support to ever think of trying it again.
I remember going to a DSC124(?) training class some years back (back when the chip was new). The instructor could not even give me a copy of the example code we did in class, because, god forbid, I would want to make your chip work when I got back to my office (I'm talking about something on the order of code showing how to use the MAC on this part, not any real software).
Thank you for your suggestions about writing TI support. It's been two years since my company followed through on my recommendation to abandon our last TI part (not including DACs), so I'm grateful to say that I require no more support from your company. After years of having email and phone calls ignored, playing shuffle-the-FAE, being pawned off on third parties, and being told outright that software designed to operate some part or feature is unsupported and yet documents for that same part are unavailable, I have no interest in seeing TI improve. Your issues are political, not technological, and I have no confidence that there is interest in resolving these. I will pursue a different strategy: I will deal with your competitors. What they lack in hardware design skill, they make up in support. TI's anemic support response is a greater risk to a project I undertake than any silicon bug.
Love,
joe
Interesting theory. However, we didn't pay for hardware with it, and have had no problem running the software with no hardware attached or with new hardware we've made (and different JTAG devices). I don't remember what the emulator was, but thankfully I never have to look at it again.