I work as a programmer in the retail industry, and in previous employment have dealt with ERP integration and extending legacy systems. I can tell you with absolute confidence that certain industries do need completely custom software to work properly - grocery stores, bookstores, and clothing stores all have different needs, different workflows, and different requirements. A cash register is a cash register, yes, but everything from dealing with expiration tracking and sales by weight to street dates to clothing sizes to custom orders to EDI interfaces are handled by custom software.

We primarily work with the music industry, and I have to deal with EDI from 4 different POS / Inventory / bordering on full ERP application vendors (some of which have been heavily customized for specific clients) and 2 different distributors, and will be spinning up 3 more distributors in the next year. Our e-commerce system is off-the-shelf for our industry (we can spin up a new customer who has no need for custom EDI integration in less than a day), and we have rescued a number of smaller operations who tried to develop their own system, or adapt various open-source shopping cart applications.

Our software would be of no use whatsoever to the manufacturers and medical, real estate, and legal offices I have dealt with in previous jobs. A completely different regulatory environment, different expectations, and different reporting requirements make any one-size-fits-all useless. That's a perilously bad attitude to take - some things, like payroll and HR, are relatively common across industries, but not understanding how business workflows differ from company to company shows a lack of professionalism. You think UPS uses an off-the-shelf software package? Or Greyhound? I can speak to both of them - they both developed in-house, because there was no software that covered their needs.

My business programming teacher back in high school put it this way: You will be working with obsolete technology, writing boring code to make distinctions between states that you really don't care about or even understand all that well, and will be ignored unless you make a mistake. Your job is to disappear into the background and make the business run smoothly. If your ego can't deal with that, leave this class now, because you will not make it in programming.

Look - there were no deaths in Vietnam War protests before Kent State. There is always a first episode of massive violence, and nobody knows when that will come.

We are only in the very beginning of these protests - as the economy gets worse, more people will join them. As police forces make more blunders, they will react with more force. We are on a path that very soon now will be irreversible - of peaceful revolution or bloody ruin. The status quo will not hold - Communism is more popular than Congress these days.

Have you ever read about the few airborne nuclear propulsion tests they did? Running a small research reactor in a plane, the small amount of shielding they could put in it left the aircraft so radioactive from neutron activation that they couldn't get near it for weeks.

Plus, the plutonium for RTGs is some REALLY nasty stuff. It would be a lot safer if we could put that reactor in lunar orbit - since the RTGs are only used on deep-space missions, and we're getting pretty good at remote processing of fuels, someone will put the idea together. However, ther would never be enough to justify the huge costs associated with it...

It does tend to look that way, yes, but Perl still puts a lot of emphasis on metacharacters to imply functionality. I still keep a cheat sheet of the builtins, and I've been working in Perl for a year and a half straight...

Python, on the other hand, is very easy to just write. No weird '$@' or '$_' or '<=>' functions, or dereferencing an array ref into an array with @$arrayref...

Reboots are not necessary on many machines right now - I have to remind my boss to reboot every few weeks when something finally goes wonky in the network settings on his Mac laptop. Standby mode lasts for a very long time now... and most required reboots are from operating system updates. With modern SSDs, you don't even need to wait that long to boot. My work machine with a modern SSD takes about 7 seconds to boot Windows 7. My home machine, with less services to start, boots in about 4.

But honestly, they may be saying that, but it's not like DRAM speeds will be sitting still. And a store/load cycle that can compete with flash is an order of magnitude slower than one that can compete with modern DRAM chips. But don't let that get in the way of crystal ball gazing.

I realized in the early 90s, as soon as they announced a proper cure for HIV, there will be f**king in the streets. It is impossible to say how much of a stamp of fear AIDS has put on a lot of people. We will be heading for a free-love generation that made the 60s look like a bunch of tossers...

We also have a couple on Monument Ave. in Richmond, VA, ever since the early 1900's. Mostly around Confederate heroes from the Civil War. Get a lot of accidents around them, too...

Use it at work to replace all the MySQL fulltext indexes we were using for a (rather bad) search interface when we moved to InnoDB. Don't miss the old search at all. I may be grabbing this book, since my boss asked for predictive search in our app soon...

If people didn't go to the movies, they wouldn't make money. They know (Hollywood, that is) that they'll get a $12 ticket from enough aging geeks for a lame turd of an eye-poking 3D pile of mawkish sentimental rehash sludge to make their money back. Plus, the movie tie-ins are worth a lot of money - how much does McDonald's pay for the rights for those Happy Meal Toys? Mattel? The video game rights?

I guarantee this will make its money back. No matter how bad it is - they'll make it in some kind of tax shelter state or country which has a huge tax rebate on movie production, count the full cost of production against the bottom line, and claim it lost money to all the people involved with the actual production. All while the money people make a healthy profit.

So, would you go see it? Of course you would. Even if it's mediocre. They just have to buy enough good reviews to get you into the theater. They don't have to actually work.

Now, on a more serious note, let's see who the creative team is that is working on it before saying it'll suck. There are some very good writers, directors, and cinematographers out there who won't give it the "G.I. Joe: Rise of My Gorge" treatment.

We converted all our customers over to Gmail before I started working at my current job. Now, this was after the old mailserver got hacked (long story) but it makes life a hell of a lot easier for communication. IMAPS and POP3S out of the box, decent web UI, and it would have to be a spectacularly retarded sysadmin that would block inbound Gmail.

I did run a mailserver at my old job - actually, three of them in a load-balancing arrangement. I'm much happier with not having to deal with the problems in running a modern mail server.

I dunno about that - I earned a lot of military awards in my science fair years, but I was doing random number algorithm testing. At the time I didn't realize that was one of the core problems in effective crypto... I still have some of the awards in a box of childhood stuff at my parents' house.

I'm in that situation - we've got a proprietary point of sale system that a lot of our customers run, that was written for SCO OpenServer. To move to Linux would cost $7,000 - $15,000 in license fees for the license transfer, so they're staying on SCO. An SCO OpenServer 6 license is a lot cheaper than the Thoroughbred software stack it's written in.

It's not a bad system - the problem with SCO was never their technical abilities. I really can't complain about its stability either - that damn things just keep running, and the most we have to do is replace tape drives and fans every once in a blue moon...

Actually, it doesn't. The interfaces can be named the same on reboot, but the initial numbering is semi-random.

The problem arises when you're trying to deploy a large number of machines, and you know which devices are where on the PCI buses (modern servers are coming with 4 Ethernet ports on the motherboard now). That way, you can assign VLANs and IPs to specific ports in a kickstart file and the installer doesn't have to play the "which interface is eth1" game. Which is not fun. We should not be relying on automagic configuration for something as basic as ethernet...

<rant>this is why I don't like the /dev/sd* interfaces in Linux - you have to dig deep into /proc to find out which port SATA and SAS devices are on</rant>

This doesn't get into crappy BIOSes that enumerate devices badly, or NICs that have a bad habit of initializing late.

At my last job we sold CentOS-based routers and fileservers. I'd rename the interfaces ethWAN and ethLAN in the /etc/sysconfig/network-scripts/ifcfg-eth* scripts. And then labeled the interfaces on the box for the installer. Worked pretty well, until we started messing with VLANs, and the init scripts choked on VLANs attached to renamed interfaces.

Debian's udev rules also tried it, but it didn't work out so well for systems that had a lot of changes - we've got machines in the field that are on /dev/eth8...

I got to see a presentation given by a nuclear scientist who went there last year on a vacation - it can be done, but it takes at least one person in the tour that speaks decent Russian. Wild pictures - growing up at the end of the Cold War, seeing an abandoned, looted Soviet-era city is a little creepy.

Scratch that, a whole bunch of creepy.

The guy doing the presentation had his own geiger counter, and was showing just how hot some areas of Chernobyl still were. It was wild stuff, and sobering...