As someone who has programmed VxWorks (including AE) for several years, I can say AE is a buggy piece of crap. We moved to AE for our project and eventually had to dump it since it was so buggy and slow. Also, as far as flash filesystems go, VxWorks ONLY SUPPORTS FAT, and not even FAT32, so it isn't a very robust filesystem. Not only that, because it's FAT there is no wear level support. I believe there also isn't the equivelent of chkdsk either. I also imagine that it can't handle faults in the filesystem (as if anything ever could deal with faults in a FAT filesystem very well).
With VxWorks you can often get away without any filesystem because all the code is linked together in one big monolithic file. Separate tasks are not separate files (although you can have loadable object files).
Yes, AE does provide memory protection domains, but it still doesn't clean up after a task dies. Sure, you can free the memory, but not open files, semaphores, pipes, or other things. Malloc in AE is improved over the braindead implementation in standard VxWorks, but it still has a long way to go. For example, it can't free up open file descriptors, semaphores, or other items associated with a task because a task usually isn't associated with it. So if you have a task that acquired a semaphore and dies, that semaphore will never be released.
Hell, Wind River couldn't even get malloc right! Their malloc has got to be the worst implementation I've ever seen! They place free blocks in sorted order (smallest to largest) in a linked list after attempting to combine a new free block with neighboring free blocks. The next time you allocate, it walks the entire linked list until it finds a block large enough! In our case we wound up with tens or even hundreds of thousands of small blocks causing our watchdog timer to kick in because malloc became impossibly slow. AE improves this to use a tree instead of a list, but it still fragments. I ripped out the Wind River implementation and replaced it with Doug Lea's dlmalloc and all our malloc problems were solved, and the fragmentation went from tens of thousands of fragments to only a few dozen.
For an RTOS being pushed for networking it isn't very good there either. It comes with an ancient BSD TCP/IP stack. If you have a device and want to see if it runs VxWorks, just run nmap against it. If it says TCP sequence number guessing is trivial, you can bet it's probably running VxWorks.
In todays world, VxWorks doesn't cut it any more. Any complex project should choose a real OS like QNX or even embedded Linux over VxWorks. For realtime, Linux usually isn't very good, but Timesys appears to have solved that problem nicely.
VxWorks isn't even that good at realtime. Usually you can't get any better resolution than half the system tick rate (usually 10ms), so you can't get better than 20ms of resolution in many cases.
I've also heard many rumours that Wind River is dropping AE, or at least not pushing it. We're not the only ones to have been burned by it. I've heard of only one other company that used it, and they were also burned. I think it was a startup that went out of business.
In VxWorks, all tasks share the same memory space. Think of every "task" as really a thread and you get the idea. In other words, if a "task" dies, the only way to clean up the system is to reboot.
Also, VxWorks doesn't scale. The more tasks you have, the slower it runs (i.e. no O(1) scheduler). And with the shared memory, the more complex the code, the harder it is to debug and develop a stable system.
QNX would have been a much better solution. In QNX, the core OS is very small, and if a task dies it can easily be restarted. In QNX, everything is a task with memory protection. The TCP/IP stack is separate from the core OS, for example, as are all the other drivers. If a driver crashes, it won't take the OS with it. Context switching in QNX is also very fast, faster than VxWorks even though memory protection is involved.
I hate to follow up to my own post, but I heard on NPR that the problem is in the Flash memory.
Usually in VxWorks everything is compiled and linked into a single binary image (i.e. no filesystem). For flash, the only built-in file system is FAT, not even FAT32. Due to this, it makes the flash much more critical. Fat itself is not very robust.
Ideally they would have at least 2 copies of the image in flash and switch to the secondary if the primary fails a CRC or other validation test. Also, it should have been designed to survive a flash chip dying. I can see that it would be easy for the flash to get corrupted due to the radiation. Apparently they're working around it by bypassing the flash and just using RAM.
I would have thought that the flash subsystem would be designed with some fairly healthy ECC (i.e. handling bit errors at the same time at least one flash chip is dead). Maybe go so far as 3 flash banks with ECC for triple redundancy.
It would be interesting to see how the computer of the Mars rover was designed.
I wouldn't brag. I've been programming VxWorks for several years now and all I can say is it's a piece of crap for a complex system.
VxWorks does not provide any memory protection (well, AE does, but it's so buggy nobody uses it).
If a task dies, it does not clean up after it. All memory is global, i.e. any task can overwrite memory for any other task.
Wind River couldn't even implement a decent malloc implementation. I had to replace it with Doug Lea's DLMalloc code (which glibc's malloc is based off of). It fragments horribly, and becomes increasingly slower the more free blocks exist.
Just by replacing malloc, I brought the time down on our box from 50 minutes to under 3 minutes and went from tens of thousands of fragments to a couple of dozen.
If you want a reliable embedded system with a lot of complexity, go with QNX or perhapse a good embedded Linux (I like Timesys Linux myself - good realtime support).
At least with QNX if there's a problem in a task, it's much easier to isolate it and not kill the entire system. As it is on the product I'm working on, if a task dies about the only way to recover is to reboot. Also, VxWorks has piss-poor built-in debugging support. Sometimes you can get a stack trace. Tracing the heap is virtually impossible (and because it's a global memory pool, you don't even know what blocks were allocated by what task or even how much memory each task has allocated). In the product I'm working on I added such support to find memory leaks and detect memory corruption.
VxWorks AE does provide memory protection. We tried to use it, but it was so buggy and slow we had to drop it and go back to standard VxWorks.
VxWorks hasn't really changed in the last few years and Wind River is losing customers like crazy to the better alternatives. They're hemmoraging money at an astronomical rate and quickly losing market share to the likes of QNX and Linux.
Even the realtime performance of VxWorks isn't that great. The finest granularity for a reliable timer is 1/2 the system tick rate (often no more than 20ms resolution).
VxWorks doesn't have a shell as such either. The commands you type in are functions with parameters to those functions. You can do things like my_global = global_a + 7
or
my_func(&my_global, 3)
on the command line, but it's not at all like a traditional command line.
Most real-time Linux implementations arn't all that great either from my research into it. Most don't deal with priority inversion, or require a completely separate set of APIs for RT tasks (i.e. RT Linux). I found Timesys Linux to solve most of these issues and it looks like our next generation will be based off of either Timesys Linux or QNX.
In this case it is somewhat useful, but the _ defeats the purpose since you need to keep hitting SHIFT - to get _. For me, at least, it's just easier to hold down the SHIFT key the whole time. I should have included _ in the list of keys I'm constantly using.
I also have an old Northgate Omnikey keyboard and generally love it, except when I type the same letter quickly twice I often get 3 letters. Their keybounce algorithm never worked right for me, but I did love the keyboard feel, and the fact that they added an extra * key to the right of the spacebar.
So far I have yet to see a keyboard truely optimized for programmers. I don't want all the multimedia and email crap keys. The best keyboard I've used to date is the Sun keyboard (that Front key is extremely useful).
What I want is a keyboard:
1. Get rid or move the fscking capslock key out of the way. It's a waste of prime real-estate.
2. Make another row of keys so I don't have to keep hitting shift for all the symbol keys. This is really useful for C, C++, Java, Perl, and script programming, and probably a bunch of other languages as well.
3. If you split the keys like the MS Natural Keyboard, I think a few additional keys could be moved to the center to reduce stress on the pinky. I.e. shift and possibly Return.
4. Implement keys on the side like the Sun keyboard. Sun has a reasonably good selection of keys to the left where the function keys used to be on old keyboards. Front, cut, copy, paste, and find are quite useful there.
5. Move control back where it belongs, where they now place the CAPS lock key. Caps lock is only good for AOL users and should be eliminated for the most part. Or else, move it somewhere out of the way.
I shouldn't have to keep hitting shift for common keys when programming like () & # - + | ? < > : " { }. As a C programmer I often use the shifted key far more often than the non-shifted (i.e. () {})
I'd pay good money for such a keyboard. Maybe since Logitech's headquarters is next door to where I work maybe I should walk over there and suggest it to them.
I recommend setting up a Privoxy proxy. I've been using it and it does an excellent job of blocking ads, even with its default filters. Combined with Mozilla and Konqueror's popup blocking I rarely see any ads on the web now. As for TV, that's what my Replay is for. It does a decent job of automatically skipping over ads, or when it doesn't, the 30 second skip works nicely.
It is possible to be mostly ad free with a bit of effort.
I look forward to a decent standard for computer audio.
44.1Khz sampling and 16 bits are barely adequate depending on the music. When music has a large dynamic range from quiet pieces to loud pieces, 16 bits doesn't cut it. Also, all the filtering necessary for the 44.1Khz sampling rate also tends to screw up the sound. Before sampling at 44.1Khz you must filter out everything above 22050, and there's no such thing as a perfect brick wall filter. Filters screw up the phase and introduce all sorts of ripples the closer you get to the cutoff frequency. The higher frequency will also help improve the clocking. I listened to a high-end DAC connected to a good CD transport with 2 digital interfaces. One was the standard SP/DIF interface and the other had all the signals separated so the clock and data are never combined and hence no clock jitter. Digital is digital, right? I didn't expect to hear a difference, but I did. DACs do not like jitter. The other interface sounded more detailed. Of course this wasn't on a standard home stereo system either.
This will also remove a lot of the audio processing that currently occurs for 44.1KHz. I.E. virtually all CD players, etc. oversample and interpolate the signal to try and clean it up before filtering. You need to filter the output of the DACs too to get rid of harmonics introduced due to stair stepping and whatnot.
Since the Transmeta is designed around code morphing and dynamically optimizing the code based on execution patterns, perhapse a better solution would be to develop an instruction set much friendlier to code morphing, similar to the Java byte code. It may be possible to implement a more compact and easier to interpret instruction set where the compiler could better take advantage of the chip internals.
I'd love to see an ITX Transmeta-based motherboard to replace my aging Pentium II based firewall and file server. I have a Crusoe based FrontPath Tablet PC running Linux that seems to work well except for the limited memory. I use it as a remote X server with a USB keyboard attached.
I have been running KDE on Solaris for quite some time. I wrote the ARTS Solaris sound daemon so I could listen to my ogg files. Generally I have had few problems with KDE on Solaris. The only problems I have are missing features in Sun's X implementation (i.e. no RENDER) and the huge number of additional libraries I need to compile to get everything working. I've also come across a number of nasty bugs in GCC when building KDE, but GCC 3.3.1+ seems to work fairly well.
I think the only reason Sun chose Gnome over KDE was the QT licensing issue. Other than that, KDE on Solaris rocks. It's also fairly stable.
I don't know why Sun has stuck with that god-aweful CDE for so long. CDE just plain sucks.
I've never downloaded the pre-built binaries, though. I need to control where it gets installed since it's running in a corporate environment and I feel more comfortable having compiled it myself. As it is, I usually need to patch a few files anyway for our environment.
Since I made it available, we've had many engineers switch from CDE to KDE. We had one lone GNOME user, but he switched as well (Sun's GNOME was too slow compared with KDE).
Out of curiosity I took a quick look at the code. Right off the bat I see what MAY be new problems introduced by this code (I'm not a Windows programmer or user so I can't be sure), but I see what looks like a memory leak for every URL. In CIETray::BeforeNavigateEvent a new destination string gets allocated via malloc.
1. *dest is not verified to be non-NULL. 2. *dest does not appear to be freed, resulting in a 256 byte memory leak per URL. 3. URLs greater than 255 characters in size might have problems since the length 256 is hard-coded into the code. 4. It may be a similar problem for *url.
Granted, I only spent 5 minutes glancing at the code, but I don't like what I see, and the cure might be worse than the disease. I'd like to see a serious audit of this code before trusting it.
I'm not sure if these are actual problems or not since I don't have the time to learn all the Windows APIs and programming, but it looks highly suspect to me. I do embedded C and Unix programming, not Windows programming.
Years ago I bought a Nikon 6006 camera body and I've been very happy with it. On Ebay I see them going for $50-150. This camera has lots of features, auto focus, and numerous lighting options. It can be as manual or as automatic as you want. Also, it takes all the standard Nikon lenses.
In automatic mode it generally does a pretty good job, and the auto focus works quite well. I typically use it with a Sigma 28-105mm lense and a Sigma 24mm wide-angle lense.
Of course now I'd go with a digital camera, but I'm waiting for the price to drop a bit on one that takes the same Nikon lenses.
I am also rather fond of Netgear. I bought a FR314 broadband router several years ago. It has a limitation of 8 users unless you buy a license for more clients. I'm already at the 8 user limit and have had some issues with this. I went to their website looking to buy the license to expand the number of clients but couldn't find it, so I sent a request to their tech support.
They responded within 24 hours and gave me all the keys for enabling all the additional features on it (VPN, 20 users, and 40 users) for free since they no longer are supporting the box.
I just picked up a D-Link router on sale for $10 which I was thinking of replacing my Netgear with, but I found that my Netgear has better features in many ways, especially when it comes to logging and filtering (i.e. blocking Active X, Java, etc.).
I also have one of their print servers and have never had any problems with either of these products (although occasionally I need to reset the firewall).
As a long-time SuSE Linux user it sounds like 9 is a nice upgrade. I've already ordered the upgrade from 8.2 to 9.
My experience with SuSE was that 8.0 was good, 8.1 was buggy, and 8.2 has been quite stable. They addressed many of my complaints about missing modules in YaST in 9.0, which is good. I also like the fact that they're using GCC 3.3.1, which IMO is *much* more stable than 3.3 or the pre-3.3 SuSE included in 8.2 (although 3.3.2 was just released).
I've already upgraded my SuSE 8.2 to use KDE 3.1.4 (which is available via FTP from the supplementary section of the SuSE FTP site (and mirrors), and have found it to be quite stable. It looks like SuSE 9.0 is basically just an evolutionary step from 8.2. I think the release number should really have been 8.3, although I guess they're under pressure from Redhat. I also like the fact that they backport a lot of features from the 2.6 kernel back to 2.4 (the SuSE kernel scheduler is basically taken straight from 2.6). When Linus came out with the interactive patch that makes X much more responsive I was able to verbatim take the patch and apply it to the SuSE Linux kernel.
I also love the fact that SuSE comes on DVD. It's nice to not have to swap between lots of CDs when installing various packages.
And finally, YaST is a great tool that always surprises me. Last night I went to enable telnet and rlogin support on a machine in our lab (security is no issue) in xinetd and Yast immediately requested that I install the appropriate CD and installed the RPM packages required (they were not already installed).
What advantage would SCO have by nullifying the GPL? Perhapse they discovered that the source of the code in question which they claim was copied out of SVr4 instead was copied from Linux into Unixware? If this is the case, then SCO is screwed (as if they were not screwed anyway). Perhapse they know this and thus are trying to limit any damages they might have due to this.
After all, they have offered absolutely zero credible evidence to back their claims that the Linux kernel contains their code.
I don't think anyone is arguing against patents, only against patenting obvious ideas. The patenting of business models, obvious algorithms, and so forth should not be allowed, especially for software. I should know, I'm currently going through the patent process.
I also think it is important to see how the patent holder deals with patents. For example, the company I work for is after as many patents as they can get. This is not to go out and sue everyone, but to protect itself against other companies like IBM, which holds so many patents it's impossible to not infringe on.
Patents should be for non-obvious solutions. Buy it now is pretty obvious, as is Amazon's one click shopping. Obvious software algorithms and methods should also not be patentable.
The problem in the US is that since the patent office is underfunded they leave the settlement of patents up to the courts. The problem here is that judges and juries are not technical people and aren't qualified to make these decisions. The bar for accepting a patent needs to be raised significantly IMO.
It is interesting that this article should come out at this time. Someone just gave me a ProGear frontpath tablet PC based on the Transmeta Crusoe. This tablet came pre-installed with a Linux distribution based on Slackware 7.1. It has a dumbed down X interface with handwriting recognition and the ability to rotate the display on the fly.
I have been hacking with it to try and make it more usable. The only tool installed on it was Netscape. After I managed to get an Xterm session up, I installed GCC and just got it working with a Cardbus 10/100 Ethernet controller.
Even though this tablet only has 64MB of memory (48MB usable after Crusoe), it still feels quite snappy, even with X and netscape running. It compiled the Linux kernel reasonably fast.
Unfortunately, ProGear was purchased by Sonic Blue and is basically no more. It looks like the later units had 128MB of RAM and came default with wireless. They had either Linux or Windows installed on them.
I also worked at one of the first developers of tablet PCs. Years ago I worked at GRiD Systems, which made tablet PCs with handwriting recognition. They even had a "notebook" where the display flipped up to reveal a keyboard underneath. What was unique, though, was that when closed, the display faced up, not down, and no rotation was necessary. Of course it had a pen interface as well. To give an idea of the timeframe, the notebook was based on a leading edge 80486 CPU and the tablet PCs were based on either an 8088 or a 80486SL processor.
I would *love* to see operator overloading. It would actually make Java much more useful for scientific tasks which involve things like vectors, matricies, or complex numbers. I'm also sure it would also be helpful in other areas.
Slashdot Mirror
As someone who has programmed VxWorks (including AE) for several years, I can say AE is a buggy piece of crap. We moved to AE for our project and eventually had to dump it since it was so buggy and slow. Also, as far as flash filesystems go, VxWorks ONLY SUPPORTS FAT, and not even FAT32, so it isn't a very robust filesystem. Not only that, because it's FAT there is no wear level support. I believe there also isn't the equivelent of chkdsk either. I also imagine that it can't handle faults in the filesystem (as if anything ever could deal with faults in a FAT filesystem very well).
With VxWorks you can often get away without any filesystem because all the code is linked together in one big monolithic file. Separate tasks are not separate files (although you can have loadable object files).
Yes, AE does provide memory protection domains, but it still doesn't clean up after a task dies. Sure, you can free the memory, but not open files, semaphores, pipes, or other things. Malloc in AE is improved over the braindead implementation in standard VxWorks, but it still has a long way to go. For example, it can't free up open file descriptors, semaphores, or other items associated with a task because a task usually isn't associated with it. So if you have a task that acquired a semaphore and dies, that semaphore will never be released.
Hell, Wind River couldn't even get malloc right! Their malloc has got to be the worst implementation I've ever seen! They place free blocks in sorted order (smallest to largest) in a linked list after attempting to combine a new free block with neighboring free blocks. The next time you allocate, it walks the entire linked list until it finds a block large enough! In our case we wound up with tens or even hundreds of thousands of small blocks causing our watchdog timer to kick in because malloc became impossibly slow. AE improves this to use a tree instead of a list, but it still fragments. I ripped out the Wind River implementation and replaced it with Doug Lea's dlmalloc and all our malloc problems were solved, and the fragmentation went from tens of thousands of fragments to only a few dozen.
For an RTOS being pushed for networking it isn't very good there either. It comes with an ancient BSD TCP/IP stack. If you have a device and want to see if it runs VxWorks, just run nmap against it. If it says TCP sequence number guessing is trivial, you can bet it's probably running VxWorks.
In todays world, VxWorks doesn't cut it any more. Any complex project should choose a real OS like QNX or even embedded Linux over VxWorks. For realtime, Linux usually isn't very good, but Timesys appears to have solved that problem nicely.
VxWorks isn't even that good at realtime. Usually you can't get any better resolution than half the system tick rate (usually 10ms), so you can't get better than 20ms of resolution in many cases.
I've also heard many rumours that Wind River is dropping AE, or at least not pushing it. We're not the only ones to have been burned by it. I've heard of only one other company that used it, and they were also burned. I think it was a startup that went out of business.
In VxWorks, all tasks share the same memory space. Think of every "task" as really a thread and you get the idea. In other words, if a "task" dies, the only way to clean up the system is to reboot.
Also, VxWorks doesn't scale. The more tasks you have, the slower it runs (i.e. no O(1) scheduler). And with the shared memory, the more complex the code, the harder it is to debug and develop a stable system.
QNX would have been a much better solution. In QNX, the core OS is very small, and if a task dies it can easily be restarted. In QNX, everything is a task with memory protection. The TCP/IP stack is separate from the core OS, for example, as are all the other drivers. If a driver crashes, it won't take the OS with it. Context switching in QNX is also very fast, faster than VxWorks even though memory protection is involved.
-Aaron
I hate to follow up to my own post, but I heard on NPR that the problem is in the Flash memory.
Usually in VxWorks everything is compiled and linked into a single binary image (i.e. no filesystem). For flash, the only built-in file system is FAT, not even FAT32. Due to this, it makes the flash much more critical. Fat itself is not very robust.
Ideally they would have at least 2 copies of the image in flash and switch to the secondary if the primary fails a CRC or other validation test. Also, it should have been designed to survive a flash chip dying. I can see that it would be easy for the flash to get corrupted due to the radiation. Apparently they're working around it by bypassing the flash and just using RAM.
I would have thought that the flash subsystem would be designed with some fairly healthy ECC (i.e. handling bit errors at the same time at least one flash chip is dead). Maybe go so far as 3 flash banks with ECC for triple redundancy.
It would be interesting to see how the computer of the Mars rover was designed.
I wouldn't brag. I've been programming VxWorks for several years now and all I can say is it's a piece of crap for a complex system.
VxWorks does not provide any memory protection (well, AE does, but it's so buggy nobody uses it).
If a task dies, it does not clean up after it. All memory is global, i.e. any task can overwrite memory for any other task.
Wind River couldn't even implement a decent malloc implementation. I had to replace it with Doug Lea's DLMalloc code (which glibc's malloc is based off of). It fragments horribly, and becomes increasingly slower the more free blocks exist.
Just by replacing malloc, I brought the time down on our box from 50 minutes to under 3 minutes and went from tens of thousands of fragments to a couple of dozen.
If you want a reliable embedded system with a lot of complexity, go with QNX or perhapse a good embedded Linux (I like Timesys Linux myself - good realtime support).
At least with QNX if there's a problem in a task, it's much easier to isolate it and not kill the entire system. As it is on the product I'm working on, if a task dies about the only way to recover is to reboot. Also, VxWorks has piss-poor built-in debugging support. Sometimes you can get a stack trace. Tracing the heap is virtually impossible (and because it's a global memory pool, you don't even know what blocks were allocated by what task or even how much memory each task has allocated). In the product I'm working on I added such support to find memory leaks and detect memory corruption.
VxWorks AE does provide memory protection. We tried to use it, but it was so buggy and slow we had to drop it and go back to standard VxWorks.
VxWorks hasn't really changed in the last few years and Wind River is losing customers like crazy to the better alternatives. They're hemmoraging money at an astronomical rate and quickly losing market share to the likes of QNX and Linux.
Even the realtime performance of VxWorks isn't that great. The finest granularity for a reliable timer is 1/2 the system tick rate (often no more than 20ms resolution).
VxWorks doesn't have a shell as such either. The commands you type in are functions with parameters to those functions. You can do things like my_global = global_a + 7
or
my_func(&my_global, 3)
on the command line, but it's not at all like a traditional command line.
Most real-time Linux implementations arn't all that great either from my research into it. Most don't deal with priority inversion, or require a completely separate set of APIs for RT tasks (i.e. RT Linux). I found Timesys Linux to solve most of these issues and it looks like our next generation will be based off of either Timesys Linux or QNX.
-Aaron
In this case it is somewhat useful, but the _ defeats the purpose since you need to keep hitting SHIFT - to get _. For me, at least, it's just easier to hold down the SHIFT key the whole time. I should have included _ in the list of keys I'm constantly using.
I also have an old Northgate Omnikey keyboard and generally love it, except when I type the same letter quickly twice I often get 3 letters. Their keybounce algorithm never worked right for me, but I did love the keyboard feel, and the fact that they added an extra * key to the right of the spacebar.
-Aaron
So far I have yet to see a keyboard truely optimized for programmers. I don't want all the multimedia and email crap keys. The best keyboard I've used to date is the Sun keyboard (that Front key is extremely useful).
What I want is a keyboard:
1. Get rid or move the fscking capslock key out of the way. It's a waste of prime real-estate.
2. Make another row of keys so I don't have to keep hitting shift for all the symbol keys. This is really useful for C, C++, Java, Perl, and script programming, and probably a bunch of other languages as well.
3. If you split the keys like the MS Natural Keyboard, I think a few additional keys could be moved to the center to reduce stress on the pinky. I.e. shift and possibly Return.
4. Implement keys on the side like the Sun keyboard. Sun has a reasonably good selection of keys to the left where the function keys used to be on old keyboards. Front, cut, copy, paste, and find are quite useful there.
5. Move control back where it belongs, where they now place the CAPS lock key. Caps lock is only good for AOL users and should be eliminated for the most part. Or else, move it somewhere out of the way.
I shouldn't have to keep hitting shift for common keys when programming like () & # - + | ? < > : " { }. As a C programmer I often use the shifted key far more often than the non-shifted (i.e. () {})
I'd pay good money for such a keyboard. Maybe since Logitech's headquarters is next door to where I work maybe I should walk over there and suggest it to them.
-Aaron
I recommend setting up a Privoxy proxy. I've been using it and it does an excellent job of blocking ads, even with its default filters. Combined with Mozilla and Konqueror's popup blocking I rarely see any ads on the web now. As for TV, that's what my Replay is for. It does a decent job of automatically skipping over ads, or when it doesn't, the 30 second skip works nicely.
It is possible to be mostly ad free with a bit of effort.
-Aaron
I look forward to a decent standard for computer audio.
44.1Khz sampling and 16 bits are barely adequate depending on the music. When music has a large dynamic range from quiet pieces to loud pieces, 16 bits doesn't cut it. Also, all the filtering necessary for the 44.1Khz sampling rate also tends to screw up the sound. Before sampling at 44.1Khz you must filter out everything above 22050, and there's no such thing as a perfect brick wall filter. Filters screw up the phase and introduce all sorts of ripples the closer you get to the cutoff frequency. The higher frequency will also help improve the clocking. I listened to a high-end DAC connected to a good CD transport with 2 digital interfaces. One was the standard SP/DIF interface and the other had all the signals separated so the clock and data are never combined and hence no clock jitter. Digital is digital, right? I didn't expect to hear a difference, but I did. DACs do not like jitter. The other interface sounded more detailed. Of course this wasn't on a standard home stereo system either.
This will also remove a lot of the audio processing that currently occurs for 44.1KHz. I.E. virtually all CD players, etc. oversample and interpolate the signal to try and clean it up before filtering. You need to filter the output of the DACs too to get rid of harmonics introduced due to stair stepping and whatnot.
Since the Transmeta is designed around code morphing and dynamically optimizing the code based on execution patterns, perhapse a better solution would be to develop an instruction set much friendlier to code morphing, similar to the Java byte code. It may be possible to implement a more compact and easier to interpret instruction set where the compiler could better take advantage of the chip internals.
I'd love to see an ITX Transmeta-based motherboard to replace my aging Pentium II based firewall and file server. I have a Crusoe based FrontPath Tablet PC running Linux that seems to work well except for the limited memory. I use it as a remote X server with a USB keyboard attached.
I have been running KDE on Solaris for quite some time. I wrote the ARTS Solaris sound daemon so I could listen to my ogg files. Generally I have had few problems with KDE on Solaris. The only problems I have are missing features in Sun's X implementation (i.e. no RENDER) and the huge number of additional libraries I need to compile to get everything working. I've also come across a number of nasty bugs in GCC when building KDE, but GCC 3.3.1+ seems to work fairly well.
I think the only reason Sun chose Gnome over KDE was the QT licensing issue. Other than that, KDE on Solaris rocks. It's also fairly stable.
I don't know why Sun has stuck with that god-aweful CDE for so long. CDE just plain sucks.
I've never downloaded the pre-built binaries, though. I need to control where it gets installed since it's running in a corporate environment and I feel more comfortable having compiled it myself. As it is, I usually need to patch a few files anyway for our environment.
Since I made it available, we've had many engineers switch from CDE to KDE. We had one lone GNOME user, but he switched as well (Sun's GNOME was too slow compared with KDE).
Out of curiosity I took a quick look at the code. Right off the bat I see what MAY be new problems introduced by this code (I'm not a Windows programmer or user so I can't be sure), but I see what looks like a memory leak for every URL. In CIETray::BeforeNavigateEvent a new destination string gets allocated via malloc.
1. *dest is not verified to be non-NULL.
2. *dest does not appear to be freed, resulting in a 256 byte memory leak per URL.
3. URLs greater than 255 characters in size might have problems since the length 256 is hard-coded into the code.
4. It may be a similar problem for *url.
Granted, I only spent 5 minutes glancing at the code, but I don't like what I see, and the cure might be worse than the disease. I'd like to see a serious audit of this code before trusting it.
I'm not sure if these are actual problems or not since I don't have the time to learn all the Windows APIs and programming, but it looks highly suspect to me. I do embedded C and Unix programming, not Windows programming.
-Aaron
Years ago I bought a Nikon 6006 camera body and I've been very happy with it. On Ebay I see them going for $50-150. This camera has lots of features, auto focus, and numerous lighting options. It can be as manual or as automatic as you want. Also, it takes all the standard Nikon lenses.
In automatic mode it generally does a pretty good job, and the auto focus works quite well. I typically use it with a Sigma 28-105mm lense and a Sigma 24mm wide-angle lense.
Of course now I'd go with a digital camera, but I'm waiting for the price to drop a bit on one that takes the same Nikon lenses.
I am also rather fond of Netgear. I bought a FR314 broadband router several years ago. It has a limitation of 8 users unless you buy a license for more clients. I'm already at the 8 user limit and have had some issues with this. I went to their website looking to buy the license to expand the number of clients but couldn't find it, so I sent a request to their tech support.
They responded within 24 hours and gave me all the keys for enabling all the additional features on it (VPN, 20 users, and 40 users) for free since they no longer are supporting the box.
I just picked up a D-Link router on sale for $10 which I was thinking of replacing my Netgear with, but I found that my Netgear has better features in many ways, especially when it comes to logging and filtering (i.e. blocking Active X, Java, etc.).
I also have one of their print servers and have never had any problems with either of these products (although occasionally I need to reset the firewall).
-Aaron
As a long-time SuSE Linux user it sounds like 9 is a nice upgrade. I've already ordered the upgrade from 8.2 to 9.
My experience with SuSE was that 8.0 was good, 8.1 was buggy, and 8.2 has been quite stable. They addressed many of my complaints about missing modules in YaST in 9.0, which is good. I also like the fact that they're using GCC 3.3.1, which IMO is *much* more stable than 3.3 or the pre-3.3 SuSE included in 8.2 (although 3.3.2 was just released).
I've already upgraded my SuSE 8.2 to use KDE 3.1.4 (which is available via FTP from the supplementary section of the SuSE FTP site (and mirrors), and have found it to be quite stable. It looks like SuSE 9.0 is basically just an evolutionary step from 8.2. I think the release number should really have been 8.3, although I guess they're under pressure from Redhat. I also like the fact that they backport a lot of features from the 2.6 kernel back to 2.4 (the SuSE kernel scheduler is basically taken straight from 2.6). When Linus came out with the interactive patch that makes X much more responsive I was able to verbatim take the patch and apply it to the SuSE Linux kernel.
I also love the fact that SuSE comes on DVD. It's nice to not have to swap between lots of CDs when installing various packages.
And finally, YaST is a great tool that always surprises me. Last night I went to enable telnet and rlogin support on a machine in our lab (security is no issue) in xinetd and Yast immediately requested that I install the appropriate CD and installed the RPM packages required (they were not already installed).
-Aaron
This is actually present in TimeSys Linux, which is a very cool feature, BTW. It lets you guarantee a certain amount of CPU resources and latency.
-Aaron
Salon had an excellent article a couple of days ago discussing this as well. See the article here.
Actually this was part of a headline article over at Salon.com. The article is available here.
What advantage would SCO have by nullifying the GPL? Perhapse they discovered that the source of the code in question which they claim was copied out of SVr4 instead was copied from Linux into Unixware? If this is the case, then SCO is screwed (as if they were not screwed anyway). Perhapse they know this and thus are trying to limit any damages they might have due to this.
After all, they have offered absolutely zero credible evidence to back their claims that the Linux kernel contains their code.
-Aaron
Trinity did it. She exploited the ssh hole after using NMAP on Con-Ed's computers, broke in, and shut it down.
I don't think anyone is arguing against patents, only against patenting obvious ideas. The patenting of business models, obvious algorithms, and so forth should not be allowed, especially for software. I should know, I'm currently going through the patent process.
I also think it is important to see how the patent holder deals with patents. For example, the company I work for is after as many patents as they can get. This is not to go out and sue everyone, but to protect itself against other companies like IBM, which holds so many patents it's impossible to not infringe on.
Patents should be for non-obvious solutions. Buy it now is pretty obvious, as is Amazon's one click shopping. Obvious software algorithms and methods should also not be patentable.
The problem in the US is that since the patent office is underfunded they leave the settlement of patents up to the courts. The problem here is that judges and juries are not technical people and aren't qualified to make these decisions. The bar for accepting a patent needs to be raised significantly IMO.
I think you have it wrong:
IBM = USA
Microsoft = USSR
Red Hat = South Korea
SCO = North Korea
I actually prefer whitehouse.org.
Why not just filter out all the packets with the evil bit set? This should fix the problem.
Here's the likely entire program where the code is identical between SCO and Linux:
/bin/true
/*
*This program always returns with an exit code of zero
*/
int main(int argc, char *argv[])
{
return 0;
}
It is interesting that this article should come out at this time. Someone just gave me a ProGear frontpath tablet PC based on the Transmeta Crusoe. This tablet came pre-installed with a Linux distribution based on Slackware 7.1. It has a dumbed down X interface with handwriting recognition and the ability to rotate the display on the fly.
I have been hacking with it to try and make it more usable. The only tool installed on it was Netscape. After I managed to get an Xterm session up, I installed GCC and just got it working with a Cardbus 10/100 Ethernet controller.
Even though this tablet only has 64MB of memory (48MB usable after Crusoe), it still feels quite snappy, even with X and netscape running. It compiled the Linux kernel reasonably fast.
Unfortunately, ProGear was purchased by Sonic Blue and is basically no more. It looks like the later units had 128MB of RAM and came default with wireless. They had either Linux or Windows installed on them.
I also worked at one of the first developers of tablet PCs. Years ago I worked at GRiD Systems, which made tablet PCs with handwriting recognition. They even had a "notebook" where the display flipped up to reveal a keyboard underneath. What was unique, though, was that when closed, the display faced up, not down, and no rotation was necessary. Of course it had a pen interface as well. To give an idea of the timeframe, the notebook was based on a leading edge 80486 CPU and the tablet PCs were based on either an 8088 or a 80486SL processor.
I would *love* to see operator overloading. It would actually make Java much more useful for scientific tasks which involve things like vectors, matricies, or complex numbers. I'm also sure it would also be helpful in other areas.
-Aaron