You might want to look at Bloglines. It's a free, web based, RSS aggregator.
This has the advantage of remembering which articles that you've already seen if you view your feeds from multiple locations. As it's web based, your Firefox AdBlock is built in.
It also offers a simpler interface designed for mobile devices if you have the capability of accessing the web on the move.
I discovered Tech TV through "Big Thinkers" two or three months ago. Prior to that it was a channel I just surfed over because I thought it was still ZDNet. Very much an improvement, but as you say, getting better only slowly.
While "Screen Savers" is MS centric, they do devote more time to Mac and Linux than would be dictated by userbase alone.
They are not above bashing MS, especially on security issues or when they do something stupid.
They are very much in opposition to the RIAAs online music services. They take the reasonable position that "pirating" music is wrong, but taking away the users ability to space shift their music is just as bad.
Plus, any show that has Woz' on twice in a two month period is cool by me.
I've used Oracle for about 10 years. 8 of them as a DBA. Databases have ranged from a few hundred meg on a users desktop, to 150Gb warehouses to 70Gb OLTP supporting 300+ users on High end Unix.
With anything bigger than about 20Gb think about the following :
Design for performance. Think carefully about indexing and disk layout. Don't be afraid to denormalise to cut down on complex joins.
If you are not going to have RAID 1+0, try to keep tables and indexes that will be used at the same time on different arrays.
In the case of Oracle, if you have a lot of writes, keep your Online Redo Logs off of RAID 5. Put them on a disk by themselves and use Oracles built in multiplexing to mirror them.
If you are going to have a batch run, it's much more efficient to code jobs to run in parallel rather than relying on the inbuilt parallel functions in the database. Remember that a few microseconds saved on processing each row makes a huge difference when running through a 200 million row table.
If you are rolling data out of the database after a certain time, use table partitioning by date. This allows you to drop the oldest partition instead of having to delete 20 million rows from a table. Makes the DBA's job a lot easier and mininises downtime for reorganisation.
Finally, vet all of the code designs and implementations. Most programmers are used to working on databases that are a lot smaller. I've seen a lot of systems struggling because of coders inexperience with large systems. It is much cheaper to design it right at first than to have to rearchitect later.
Hm, I did miss the VGA out port. However, the design of the machine doesn't exactly facilitate it's use. There probably isn't room on your desk for both an iMac and a large display. If you put the iMac on the floor, you struggle to reach the DVD drive.
3) When the marketing department trys to add stuff, you say "Is it in the spec?"--"Sure we can add it, but it is going to take X additional weeks".
This is probably the single largest cause of failure in the producion of new systems.
The specs keep changing, so the coding takes longer. The overall timeline is not allowed to slip and it is always the QA phase that shrinks to accommodate this. One of two things then happen, the QA people either have enough clout to delay the project, or a huge buggy mess gets released to production.
One project that I worked on went through 18 months with no progress. The coders kept leaping from place to place to try and produce the latest cool function that the users wanted.
Things didn't get sorted until a new CEO took over and said "Take these tablets of stone and engrave the system design upon them".
And lo, after 40 days and 40 nights in the wilderness, the new system was produced. And the users saw that it was good.
Unfortunatly most CEOs don't have enough political clout within a company. The IT department is doomed to produce late and buggy systems.
Thanks for the very informative post. I couldn't work out what was acting as a moderator and you've cleared that up.
As to how they got 8 times the usual quantity of U-235 in the tank, I've seen reports that the workers were carrying out 'an experiment'. If this is true, the incident has chilling echoes of the Chernobyl accident.
Slashdot Mirror
You might want to look at Bloglines. It's a free, web based, RSS aggregator.
This has the advantage of remembering which articles that you've already seen if you view your feeds from multiple locations. As it's web based, your Firefox AdBlock is built in.
It also offers a simpler interface designed for mobile devices if you have the capability of accessing the web on the move.
It's part of the missile defense plan. The moon is a great place to throw rocks from. Just ask Mike.
Of course, he may learn that The Moon is a Harsh Mistress.
If only one out of 50 of my programs worked, I would be fired immediately.
Someone tell that to Microsoft.
I discovered Tech TV through "Big Thinkers" two or three months ago. Prior to that it was a channel I just surfed over because I thought it was still ZDNet. Very much an improvement, but as you say, getting better only slowly.
While "Screen Savers" is MS centric, they do devote more time to Mac and Linux than would be dictated by userbase alone.
They are not above bashing MS, especially on security issues or when they do something stupid.
They are very much in opposition to the RIAAs online music services. They take the reasonable position that "pirating" music is wrong, but taking away the users ability to space shift their music is just as bad.
Plus, any show that has Woz' on twice in a two month period is cool by me.
Some thoughts and tips.
I've used Oracle for about 10 years. 8 of them as a DBA. Databases have ranged from a few hundred meg on a users desktop, to 150Gb warehouses to 70Gb OLTP supporting 300+ users on High end Unix.
With anything bigger than about 20Gb think about the following :
Design for performance. Think carefully about indexing and disk layout. Don't be afraid to denormalise to cut down on complex joins.
If you are not going to have RAID 1+0, try to keep tables and indexes that will be used at the same time on different arrays.
In the case of Oracle, if you have a lot of writes, keep your Online Redo Logs off of RAID 5. Put them on a disk by themselves and use Oracles built in multiplexing to mirror them.
If you are going to have a batch run, it's much more efficient to code jobs to run in parallel rather than relying on the inbuilt parallel functions in the database. Remember that a few microseconds saved on processing each row makes a huge difference when running through a 200 million row table.
If you are rolling data out of the database after a certain time, use table partitioning by date. This allows you to drop the oldest partition instead of having to delete 20 million rows from a table. Makes the DBA's job a lot easier and mininises downtime for reorganisation.
Finally, vet all of the code designs and implementations. Most programmers are used to working on databases that are a lot smaller. I've seen a lot of systems struggling because of coders inexperience with large systems. It is much cheaper to design it right at first than to have to rearchitect later.
Good luck.
2005: Microsoft promises that Windows2005 will deliver enterprise scalability and stability.
2010: Virtual Reality hits mainstream. Groinal attachment industry drives stock market to record high.
2015: Microsoft promises that Windows2020 will deliver enterprise scalability and stability.
2020: US government V's Linus torvalds anti trust case started.
2025: Rumors abound that Transmeta will finally deliver a product.
2030: WWIII starts after negotiations on VR groinal attachment trade barriers break down.
Hm, I did miss the VGA out port. However, the design of the machine doesn't exactly facilitate it's use. There probably isn't room on your desk for both an iMac and a large display. If you put the iMac on the floor, you struggle to reach the DVD drive.
They spout out a lot of impressive lie^H^H^Hbenchmarks on processor and games performance. Then they hit you with a 15" monitor.
Last time I used a 15" CRT was about 4 years ago. Even a 17" display seems small these days.
You'll take my 21" Trinitron from me, when you pry it from my cold, dead fingers.
3) When the marketing department trys to add stuff, you say "Is it in the spec?"--"Sure we can add it, but it is going to take X additional weeks".
This is probably the single largest cause of failure in the producion of new systems.
The specs keep changing, so the coding takes longer. The overall timeline is not allowed to slip and it is always the QA phase that shrinks to accommodate this. One of two things then happen, the QA people either have enough clout to delay the project, or a huge buggy mess gets released to production.
One project that I worked on went through 18 months with no progress. The coders kept leaping from place to place to try and produce the latest cool function that the users wanted.
Things didn't get sorted until a new CEO took over and said "Take these tablets of stone and engrave the system design upon them".
And lo, after 40 days and 40 nights in the wilderness, the new system was produced. And the users saw that it was good.
Unfortunatly most CEOs don't have enough political clout within a company. The IT department is doomed to produce late and buggy systems.
Thanks for the very informative post. I couldn't work out what was acting as a moderator and you've cleared that up.
As to how they got 8 times the usual quantity of U-235 in the tank, I've seen reports that the workers were carrying out 'an experiment'. If this is true, the incident has chilling echoes of the Chernobyl accident.