MIPS is still popular in some embedded areas, especially since you can buy a parameterized MIPS core ASIC macro, and built custom functions around it. I worked on a project that used one a little while ago.
In theory, when you specify the CPU, the compiler can make better choices in the instruction scheduler, since each family has different number of ALU's, multipliers, etc.
The PPC ISA has support for both big- and little-endian modes. However, the little-endian mode is a bit screwy. There are some appnotes on the Motorola website on using little-endian mode.
I don't use Linux; I use FreeBSD. I build applications from source (ie, from the ports tree rather than packages) on my work machines, and my home machines.
The biggest reason is that I can have macros in the global Makefiles that control how the application gets built (ie, globally build everything without LDAP support), and for things like PHP I can compile in exactly what I need, and not have to link against libraries I don't want.
AAC was first defined in the MPEG-2 specs (ISO/IEC 13818-7). The MPEG-4 spec (ISO/IEC 14496-3) extends it, much like the MPEG-2 audio specs (ISO/IEC 13813-3) extending the MPEG-1 audio spec. (ISO/IEC 11172-3
... but when have you ever been frusterated by the fragementation of C, C++ LISP (ok, this might be a BIT disparate).
Pre-ANSI C was a real mess. ANSI C fixed things, but it mainly took hold because gcc was available for just about any platform. However, I have been bit hard by people unknowingly using gcc extensions in code that I have had to port to systems w/o gcc.
You forgot one limit to copper: tolerance on the characteristic impedence.
One problem with twisted pair is that the twisting is what gives the pair its impedence. If you change the number of twists, you change the impedence. This is why it is important to make sure cable buildouts don't have kinks in them. The kink causes an impedence mismatch in the middle of the run, which causes signal reflections, which tend to piss off the receiver.
Similar problems can happen in coax, but the impedence is a function of the copper guage, and the size/coeffieients of the dialectrics. If you can keep tight tolerances, you have better impedence controls.
The connectors are probably the biggest cause of impedence mismatches. For coax, threaded connectors are better than bayonet, and you have to make sure they are installed properly.
Digital communication simulations need very good RNG sources, especially when simulating concatenated codes that result in very low BER. I have lost weeks worth of work because of bad and misrepresented generators.
I have read some feasibility studies for near-earth communications satellites, like high altitude blimps. The only real downside is the coverage area (since the blimp is much closer to the earth, the elevation angle is shallower). IIRC, they give pretty decent metropolitan area coverage, but not much beyond that. My antenna az/el calculator is at home. When I get back tonight I can post effective coverage areas if anyone is interested.
The test was flawed from the beginning. They use DVD's as the source, which are already compressed with a lossy method (MPEG-2). No matter what the ``quality'' of the DVD, you are still going to have artifacts.
To be honest, it's been about four years since I did any real work with digital communications. I still have all of my notes, papers, but they are stashed away.
At the time, we wrote off turbo codes as unusable for our application. The biggest problem was the complexity. The other big problem was (if I remember right) that we were concerned about performance degredation due to channel variability. If turbo coding is being considered for next gen mobile standards, then they probably figured out a way aound this.
From a theoretical standpoint, there is no difference between wired and wireless communications. The difference lies in how you model the channel. So, turbo codes can be applied to wired communications.
Turbo codes aren't really new. As the article states, they were invented in 1993. I have a big stack of papers on them at home.
Turbo codes have a few problems, though. One, they are a pain to implement and consume a lot of resources. Two, turbo codes are SNR dependent, which makes them harder to use in varried channels.
The article also makes it seem like there were no coding advances since Shannon published his orginal paper on channel capacity. Ungerbock's papers on trellis coded modulation (TCM) from 1987 or so radically altered digital communications, and he should have been mentioned. Some of the current turbo code research is trying to unify TCM and Turbo Coding (TTCM), which has great promise once it is practical.
How are they notifying their customers that they are infected? I hope it's not by email since a lot of the newer worms masquarade(sp?) as legitimate admin messages.
... only Open Source and a few small titles offer upgrades in perpetuity.
Well, if you are willing to update software yourself, then this statement is true. However, there are lots of open source projects that are stagnant, and will more than likely remain so.
This pretty much looks like one of the several PC based set-top boxes (I have worked with a bunch of them). It just comes with working FLASH'ed firmware instead of just the bootloader.
... That doesn't mean these are bad features, they're just features that are only appropriate for modern, mainstream hardware.
I think this is a really the wrong approach. Designing primarilly for new hardware hurts lots of end users, especially in poor countries. You would also be surprised to see what is still being used on the desks of most corporate users.
Core software designed for a broad audience needs to be designed for the middle ground. Not the lowest common denominator, but not brand spanking new. You then need to make it tweakable (either run-time or compile-time) to make it acceptable on low end hardware, and run well on high end hardware. Personally, I think the middle ground is a low lower than most people think.
I expect make buildworld and portupgrade gnome2 to take a long time, but the performance hit with Gnome 2.4 really shocked me.
It's open source. You have the power. Think outside of the proprietary software box!
I find this a little condescending. I started using linux in late 1991 dual-boot and by mid 1992 my machine was linux only. I use FreeBSD now, but I am well aware of how all of this works.
However, I am also a professional developer with a 9-5 (ha!) job, but I also have my own open source project, other extra-curricular professional activities, and a family.
Where do I dedicate my time?
General OS
User-interface
General applications
My project
Developemt enviroment that my project relies on
When I was a college student and single, I was able to dedicate lots of time to the early linux development, but not I have to cut back and focus on my project.
``Not true. GNOME (and KDE!) have only gotten faster and faster. The exceptions are KDE 2.0 (which is slower than 1.0; but 3.0 is faster than 2.0 and 3.2 is even faster than 3.0) and GTK (which has become a little slower but also smoother because of extensive double buffering).''
I can't comment on KDE, but when I upgraded from Gnome 2.2 to 2.4, I noticed significant performance hits. The desktop took longer to load, and in general, were noticably slower.
``On this system (Athlon 1.4 Ghz 390 MB RAM) I can definitely say GNOME 2.x is faster than 1.4. And GTK 2 feels smoother than GTK 1.''
Well, you have a nice system. My primary FreeBSD box has a 500 MHz CPU with 128M RAM. Yes, it sucks, but I was fairly disappointed when I upgraded to Gnome 2.4
Well, the article made no mention of why the patent was overturned. We should assume that is because of one or more pieces of prior art were deemed to be applicable and invalidate the patents claims, and not corporate conspiracy.
I really liked NEXTSTEP, and the NeXT cubes were pretty nice machines. They were the first I had worked with that supported dual monitors, and true color.
Slashdot Mirror
MIPS is still popular in some embedded areas, especially since you can buy a parameterized MIPS core ASIC macro, and built custom functions around it. I worked on a project that used one a little while ago.
GCC has these options, too.
In theory, when you specify the CPU, the compiler can make better choices in the instruction scheduler, since each family has different number of ALU's, multipliers, etc.
The PPC ISA has support for both big- and little-endian modes. However, the little-endian mode is a bit screwy. There are some appnotes on the Motorola website on using little-endian mode.
I don't use Linux; I use FreeBSD. I build applications from source (ie, from the ports tree rather than packages) on my work machines, and my home machines.
The biggest reason is that I can have macros in the global Makefiles that control how the application gets built (ie, globally build everything without LDAP support), and for things like PHP I can compile in exactly what I need, and not have to link against libraries I don't want.
AAC was first defined in the MPEG-2 specs (ISO/IEC 13818-7). The MPEG-4 spec (ISO/IEC 14496-3) extends it, much like the MPEG-2 audio specs (ISO/IEC 13813-3) extending the MPEG-1 audio spec. (ISO/IEC 11172-3
Pre-ANSI C was a real mess. ANSI C fixed things, but it mainly took hold because gcc was available for just about any platform. However, I have been bit hard by people unknowingly using gcc extensions in code that I have had to port to systems w/o gcc.
You forgot one limit to copper: tolerance on the characteristic impedence.
One problem with twisted pair is that the twisting is what gives the pair its impedence. If you change the number of twists, you change the impedence. This is why it is important to make sure cable buildouts don't have kinks in them. The kink causes an impedence mismatch in the middle of the run, which causes signal reflections, which tend to piss off the receiver.
Similar problems can happen in coax, but the impedence is a function of the copper guage, and the size/coeffieients of the dialectrics. If you can keep tight tolerances, you have better impedence controls.
The connectors are probably the biggest cause of impedence mismatches. For coax, threaded connectors are better than bayonet, and you have to make sure they are installed properly.
How about rigid coax or waveguide to the curb? :)
Is Interleaf still being developed? That was the standard WP/DP application for Solaris at a previous employer.
Digital communication simulations need very good RNG sources, especially when simulating concatenated codes that result in very low BER. I have lost weeks worth of work because of bad and misrepresented generators.
I have read some feasibility studies for near-earth communications satellites, like high altitude blimps. The only real downside is the coverage area (since the blimp is much closer to the earth, the elevation angle is shallower). IIRC, they give pretty decent metropolitan area coverage, but not much beyond that. My antenna az/el calculator is at home. When I get back tonight I can post effective coverage areas if anyone is interested.
I know a bunch of short term freelancers who bring their own printers to job sites along with their laptops.
The test was flawed from the beginning. They use DVD's as the source, which are already compressed with a lossy method (MPEG-2). No matter what the ``quality'' of the DVD, you are still going to have artifacts.
To be honest, it's been about four years since I did any real work with digital communications. I still have all of my notes, papers, but they are stashed away.
At the time, we wrote off turbo codes as unusable for our application. The biggest problem was the complexity. The other big problem was (if I remember right) that we were concerned about performance degredation due to channel variability. If turbo coding is being considered for next gen mobile standards, then they probably figured out a way aound this.
Turbo coding basically does block interleaving of the output of two different convolution encoders of the input.
From a theoretical standpoint, there is no difference between wired and wireless communications. The difference lies in how you model the channel. So, turbo codes can be applied to wired communications.
Turbo codes aren't really new. As the article states, they were invented in 1993. I have a big stack of papers on them at home.
Turbo codes have a few problems, though. One, they are a pain to implement and consume a lot of resources. Two, turbo codes are SNR dependent, which makes them harder to use in varried channels.
The article also makes it seem like there were no coding advances since Shannon published his orginal paper on channel capacity. Ungerbock's papers on trellis coded modulation (TCM) from 1987 or so radically altered digital communications, and he should have been mentioned. Some of the current turbo code research is trying to unify TCM and Turbo Coding (TTCM), which has great promise once it is practical.
How are they notifying their customers that they are infected? I hope it's not by email since a lot of the newer worms masquarade(sp?) as legitimate admin messages.
Well, if you are willing to update software yourself, then this statement is true. However, there are lots of open source projects that are stagnant, and will more than likely remain so.
This pretty much looks like one of the several PC based set-top boxes (I have worked with a bunch of them). It just comes with working FLASH'ed firmware instead of just the bootloader.
Especially when you consider that the source can have comments in it which would not appear in the output.
I think this is a really the wrong approach. Designing primarilly for new hardware hurts lots of end users, especially in poor countries. You would also be surprised to see what is still being used on the desks of most corporate users.
Core software designed for a broad audience needs to be designed for the middle ground. Not the lowest common denominator, but not brand spanking new. You then need to make it tweakable (either run-time or compile-time) to make it acceptable on low end hardware, and run well on high end hardware. Personally, I think the middle ground is a low lower than most people think.
I expect make buildworld and portupgrade gnome2 to take a long time, but the performance hit with Gnome 2.4 really shocked me.
It's open source. You have the power. Think outside of the proprietary software box!
I find this a little condescending. I started using linux in late 1991 dual-boot and by mid 1992 my machine was linux only. I use FreeBSD now, but I am well aware of how all of this works.
However, I am also a professional developer with a 9-5 (ha!) job, but I also have my own open source project, other extra-curricular professional activities, and a family.
Where do I dedicate my time?
General OS
User-interface
General applications
My project
Developemt enviroment that my project relies on
When I was a college student and single, I was able to dedicate lots of time to the early linux development, but not I have to cut back and focus on my project.
``Not true. GNOME (and KDE!) have only gotten faster and faster. The exceptions are KDE 2.0 (which is slower than 1.0; but 3.0 is faster than 2.0 and 3.2 is even faster than 3.0) and GTK (which has become a little slower but also smoother because of extensive double buffering).''
I can't comment on KDE, but when I upgraded from Gnome 2.2 to 2.4, I noticed significant performance hits. The desktop took longer to load, and in general, were noticably slower.
``On this system (Athlon 1.4 Ghz 390 MB RAM) I can definitely say GNOME 2.x is faster than 1.4. And GTK 2 feels smoother than GTK 1.''
Well, you have a nice system. My primary FreeBSD box has a 500 MHz CPU with 128M RAM. Yes, it sucks, but I was fairly disappointed when I upgraded to Gnome 2.4
Well, the article made no mention of why the patent was overturned. We should assume that is because of one or more pieces of prior art were deemed to be applicable and invalidate the patents claims, and not corporate conspiracy.
I really liked NEXTSTEP, and the NeXT cubes were pretty nice machines. They were the first I had worked with that supported dual monitors, and true color.